activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Quinn Stevenson <qu...@pronoia-solutions.com>
Subject Re: Artemis Core XA Example
Date Tue, 25 Oct 2016 21:51:47 GMT
I would say just use camel-jms (http://camel.apache.org/jms.html <http://camel.apache.org/jms.html>)
or camel-sjms (http://camel.apache.org/sjms.html <http://camel.apache.org/sjms.html>).

> On Oct 25, 2016, at 2:56 PM, Clebert Suconic <clebert.suconic@gmail.com> wrote:
> 
> I guess I should add that to the FAQ. I get this question once in a while.
> 
> How would we describe it? there's no need for an Artemiq-Camel
> component at the moment, just use what?
> 
> 
> Any camel specialist can provide me a simple answer to add to the doc?
> 
> On Tue, Oct 25, 2016 at 12:22 PM, Quinn Stevenson
> <quinn@pronoia-solutions.com> wrote:
>> I don’t think an equivalent for the “activemq-broker” Camel component is needed
- just my opinion there.
>> 
>> As far as a “artemis-camel” or “camel-artemis” component goes, I don’t
think one is “needed” - but I’m wondering if a specific component could provide any
value over using just the JMS abstractions.  If everything you can do in “core” is available
(or will be available) via the JMS abstractions, then I don’t see a compelling reason for
a component dedicated to Artemis - unless of course configuring the component becomes too
complex or the JMS abstractions incur too much overhead.
>> 
>> If it is decided that a specific component would provide some value, I would like
to see it in the Camel project and not in Artemis (i.e. camel-artemis instead of artemis-camel).
 Just my opinion ...
>> 
>> 
>>> On Oct 24, 2016, at 4:40 PM, Clebert Suconic <clebert.suconic@gmail.com>
wrote:
>>> 
>>> - There is an “activemq-camel” component today, and since Artemis is
>>> slated to become the next “ActiveMQ”, I was looking for functional
>>> equivalents.  This is actually what started the whole question for me,
>>> because I can do everything I need to do in core Artemis without
>>> muddying the waters with JMS abtractions.  For example, the aliases
>>> that get created for JMS destinations really confused me at first.
>>> 
>>> 
>>> We are fixing the destinations on next release (1.6.0) 1.5.0 is bound
>>> to be released this week.
>>> 
>>> 
>>> 
>>> Do we need a camel component within Artemis? if we do we can create
>>> one.. but every I ask this question I get the same answer that we
>>> don't need it given it's a bit different with Artemis.
>>> 
>>> 
>>> if you found a real need we can certainly create it.
>>> 
>>> 
>>> On Mon, Oct 24, 2016 at 1:32 PM, Quinn Stevenson
>>> <quinn@pronoia-solutions.com> wrote:
>>>> I can stick with JMS - I’ve used JMS servers for a long time, and I can
get what I need done that way.
>>>> 
>>>> There are a couple of reasons behind the question:
>>>> 
>>>> - I try to keep my dependencies to a minimum.  When I use JMS in camel currently,
I use camel-sjms whenever I can (basically whenever I don’t need XA) because the configuration
is simpler and I don’t drag in all the Spring dependencies.  The camel-sjms component does
some other things better IMO opinion as well - but it’s mostly because it’s simpler to
configure and easier to use IMO.
>>>> 
>>>> - There is an “activemq-camel” component today, and since Artemis is
slated to become the next “ActiveMQ”, I was looking for functional equivalents.  This
is actually what started the whole question for me, because I can do everything I need to
do in core Artemis without muddying the waters with JMS abtractions.  For example, the aliases
that get created for JMS destinations really confused me at first.
>>>> 
>>>> As an aside, there isn’t an equivalent for the activemq-broker component.
 I don’t really use that one, but it can be handy.  I guess I could do this with a diverter,
but I haven’t tried yet.
>>>> 
>>>> 
>>>>> On Oct 20, 2016, at 12:38 PM, Clebert Suconic <clebert.suconic@gmail.com>
wrote:
>>>>> 
>>>>> the JMS layer on Artemis is a thin layer on top of the Core API. I
>>>>> would stick to JMS or JMS2.
>>>>> 
>>>>> There are some extra controls you can have on addresses and queues but
>>>>> that will soon also come into JMS after martyn is done with the
>>>>> refactoring on addressing here:
>>>>> 
>>>>> https://github.com/apache/activemq-artemis/tree/ARTEMIS-780
>>>>> 
>>>>> On Wed, Oct 19, 2016 at 8:50 AM, Tim Bain <tbain@alumni.duke.edu>
wrote:
>>>>>> What's the reason behind wanting to avoid using the JMS layer in
favor of
>>>>>> the proprietary Artemis core API?  I've not done anything with Artemis,
so
>>>>>> this is very much a question from a place of ignorance, but Quinn's
>>>>>> statement sounded a lot like "I only want to use Hibernate-proprietary
>>>>>> APIs, none of those pesky JPA-standard ones that might let me interoperate
>>>>>> or swap underlying technologies later," and I'm curious about the
logic
>>>>>> that led to the statement...
>>>>>> 
>>>>>> Tim
>>>>>> 
>>>>>> On Oct 18, 2016 3:55 PM, "Clebert Suconic" <clebert.suconic@gmail.com>
>>>>>> wrote:
>>>>>> 
>>>>>>> On Tue, Oct 18, 2016 at 12:45 PM, Quinn Stevenson
>>>>>>> <quinn@pronoia-solutions.com> wrote:
>>>>>>>> Clebert -
>>>>>>>> 
>>>>>>>> Thank you for your input!
>>>>>>>> 
>>>>>>>> I try and avoid XA transactions whenever possible as well.
 I do have a
>>>>>>> few customers that insist on transactions when they do JMS->JMS
routes (the
>>>>>>> JMS destination are in different brokers/servers - hence the
need for XA).
>>>>>>> 
>>>>>>> got it... was just pointing my 2 cents there. Try to batch (like
1000
>>>>>>> messages & 1000 whatever else you are doing on a single TX).
if you
>>>>>>> can.
>>>>>>> 
>>>>>>>> 
>>>>>>>> This is really the last piece I need to figure out before
I’ll be able
>>>>>>> to implement Artemis (core only) into our standard flows.  I
know we can
>>>>>>> always use the JMS layer, but I’d like to be able to use just
the core if I
>>>>>>> can.
>>>>>>>> 
>>>>>>> 
>>>>>>> all the methods available on JMS for XA are also available on
>>>>>>> ClientSession. There shouldn't be any difference.
>>>>>>> 
>>>>>>> Let me know If you can't figure out, and I (or someone else)
may write
>>>>>>> an example
>>>>>>> 
>>>>>>> 
>>>>>>>> I’m planning on doing the integration in Camel, and it’s
looking more
>>>>>>> and more like I’ll need an “artemis-camel” (hosted in the
Artemis source)
>>>>>>> or a “camel-artemis” (hosted in the Camel Components source).
 Any thoughts
>>>>>>> on which would be the most appropriate place for the component?
 ActiveMQ
>>>>>>> 5.x has the activemq-camel component, but it always seemed to
me it was in
>>>>>>> the wrong place - that it should be camel-activemq.
>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> I looked at the camel component on AMQ5 at some time ago and
it would
>>>>>>> be simple to port it. I thought it wasn't needed though. but
if you
>>>>>>> need it we can add something into artemis/master just like AMQ5
has
>>>>>>> one.
>>>>>>> 
>>>>>>> Can you add it?  Send a PR... we accept PRs :)
>>>>>>> 
>>>>>>> 
>>>>>>> if you even send it soon, I'm planning a release early next week.
if
>>>>>>> it's well done (well done means.. not breaking anything) it might
be
>>>>>>> there before we release it.
>>>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> Clebert Suconic
>>>> 
>>> 
>>> 
>>> 
>>> --
>>> Clebert Suconic
>> 
> 
> 
> 
> -- 
> Clebert Suconic


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message