Re: Artemis Core XA Example

[Quinn Stevenson]

I would say just use camel-jms (http://camel.apache.org/jms.html 
) or camel-sjms 
(http://camel.apache.org/sjms.html ).

> On Oct 25, 2016, at 2:56 PM, Clebert Suconic  
> 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
>  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  
>>> 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
>>>  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  
> 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  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" 
>> 

Re: Artemis Core XA Example

[Clebert Suconic]

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
 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  
>> 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
>>  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  
 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  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" 
> wrote:
>
>> On Tue, Oct 18, 2016 at 12:45 PM, Quinn Stevenson
>>  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 

Re: Artemis Core XA Example

[Quinn Stevenson]

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  
> 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
>  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  
>>> 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  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" 
 wrote:
 
> On Tue, Oct 18, 2016 at 12:45 PM, Quinn Stevenson
>  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

Re: Artemis Core XA Example

[Clebert Suconic]

- 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
 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  
>> 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  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" 
>>> wrote:
>>>
 On Tue, Oct 18, 2016 at 12:45 PM, Quinn Stevenson
  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 

Re: Artemis Core XA Example

[Quinn Stevenson]

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  
> 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  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" 
>> wrote:
>> 
>>> On Tue, Oct 18, 2016 at 12:45 PM, Quinn Stevenson
>>>  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

Re: Artemis Core XA Example

[Clebert Suconic]

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  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" 
> wrote:
>
>> On Tue, Oct 18, 2016 at 12:45 PM, Quinn Stevenson
>>  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

Re: Artemis Core XA Example

[Tim Bain]

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" 
wrote:

> On Tue, Oct 18, 2016 at 12:45 PM, Quinn Stevenson
>  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.
>

Re: Artemis Core XA Example

[Clebert Suconic]

On Tue, Oct 18, 2016 at 12:45 PM, Quinn Stevenson
 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.

Re: Artemis Core XA Example

[Quinn Stevenson]

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).  

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.

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.  



> On Oct 18, 2016, at 10:08 AM, Clebert Suconic  
> wrote:
> 
> Most of the usecases around XA are around an application server, and
> hence around MDBs, And JMS.
> 
> ClientSession extends XAResource so you should be able to use / enlist
> on a Transaction Manager, or if you really wanted (I'm not advising
> you) you could play the TransactionManager on some fakes (for tests
> maybe).
> 
> 
> I always advise people to use messaging for fast services as much as
> possible. Transactions will introduce a point of sync and you will be
> using your messaging system pretty much as a database. if you really
> need that at least try to batch your transactions so you can scale
> without requiring many servers to support your load.
> 
> On Tue, Oct 18, 2016 at 11:06 AM, Quinn Stevenson
>  wrote:
>> Is there an example of using the Artemis Core APIs with XA?  It appears that 
>> all of the XA examples use JMS.  Am I missing something?
>> 
>> 
>> 
> 
> 
> 
> -- 
> Clebert Suconic

Re: Artemis Core XA Example

[Clebert Suconic]

Most of the usecases around XA are around an application server, and
hence around MDBs, And JMS.

ClientSession extends XAResource so you should be able to use / enlist
on a Transaction Manager, or if you really wanted (I'm not advising
you) you could play the TransactionManager on some fakes (for tests
maybe).


I always advise people to use messaging for fast services as much as
possible. Transactions will introduce a point of sync and you will be
using your messaging system pretty much as a database. if you really
need that at least try to batch your transactions so you can scale
without requiring many servers to support your load.

On Tue, Oct 18, 2016 at 11:06 AM, Quinn Stevenson
 wrote:
> Is there an example of using the Artemis Core APIs with XA?  It appears that 
> all of the XA examples use JMS.  Am I missing something?
>
>
>



-- 
Clebert Suconic