You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by Erik Aschenbrenner <ea...@icubic.de> on 2014/08/07 13:22:54 UTC
Experiences with Qpid AMQP 1.0 JMS client in production
Hi there,
does anyone have experiences with the Qpid AMQP 1.0 JMS client (v.0.28) in
production? Is it reliable to use or is it in an experimental state?
I have to build an application that is connected to a server application
that uses an AMQP 1.0 broker for its messaging API. I could not test against
the original messaging API because it is not finished yet so I only tested
my application against the Qpid Java broker (v. 0.28).
I know that there is also another AMQP 1.0 client from SwiftMQ but I did not
tested it because it is closed source and because of the SwiftMQ Client
License.
Thanks in advance!
Erik
--
View this message in context: http://qpid.2158936.n2.nabble.com/Experiences-with-Qpid-AMQP-1-0-JMS-client-in-production-tp7611393.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Experiences with Qpid AMQP 1.0 JMS client in production
Posted by Rob Godfrey <ro...@gmail.com>.
OK - I've seen the problem (basically sync_publish was changed at some
point to be a tri-state variable from just a boolean, valid values now
being "true" (always publish synchronously), "false" (never publish
synchronously) and the default (null) setting which is to publish
synchronously for persistent messages not in a transaction but
asynchronously otherwise). In that change the handling of setting via the
system property got messed up (effectively the implied null in the
connection URL overrode the explicit setting in the System property).
I've made a change to the code so that now the System property will take
effect. I've also added the ability for a connection to override the system
property to restore the "default" behaviour (using sync-publish=default or
sync-publish= (i.e. the empty string)).
I'll try to get this change incorporated into 0.30
-- Rob
On 27 August 2014 23:52, Rob Godfrey <ro...@gmail.com> wrote:
>
>
>
> On 27 August 2014 22:52, Adams, Cory <co...@paypal.com.invalid> wrote:
>
>> Rob,
>>
>> That did make a huge difference.
>>
>
> Glad to hear it!
>
>
>>
>> One question though - I tried the system property route by setting a -D
>> arg (-Dqpid.sync_publish=false) but the client did not pick up the
>> behavior. It did work with the amqp url ?sync-publish=false. Why is the
>> system property being ignored?
>>
>>
> I'll have to look into that - to be honest I just read the code and looked
> at what it should be doing... I'll give it a test in the (European)
> morning, and if there's something broken there try to get a fix in for the
> 0.30 release.
>
> Cheers,
> Rob
>
>
>> This is for the 0.28 qpid-amqp-1-0-client
>>
>> Thank you for the suggestion,
>>
>> Cory
>>
>> -----Original Message-----
>> From: Rob Godfrey [mailto:rob.j.godfrey@gmail.com]
>> Sent: Tuesday, August 26, 2014 9:59 AM
>> To: users@qpid.apache.org
>> Subject: Re: Experiences with Qpid AMQP 1.0 JMS client in production
>>
>> So, first thing to make sure would be to make sure either both clients
>> are in synchronous publish mode, or both in async... it makes a *huge*
>> difference. (To turn off synchronous publish on the 1.0 client you can
>> either set the system property "qpid.sync_publish" to false, or add the
>> connection url argument sync-publish=false).
>>
>> We'd also need to look at how much of any performance difference is down
>> to the client and how much to the broker... I see Gordon has already
>> replied saying that he's made changes broker side on the performance of the
>> C++ broker... I think it's probably also true that the Java Broker
>> performance for 1.0 will be lower simply because we've not spent the time
>> tuning it yet. Hopefully once we've got a few scenarios like yours we can
>> start to look at tuning for the use-cases our users care about.
>>
>> Cheers,
>> Rob
>>
>>
>> On 26 August 2014 16:50, Adams, Cory <co...@paypal.com.invalid> wrote:
>>
>> > Hi Rob,
>> >
>> > I will pickup the test scenario later today and provide details. We
>> > were doing simple bulk message sending to a queue with an asynch
>> > listener and then comparing that to the throughput using the swiftmq
>> > driver. This was against the qpid c++ broker.
>> >
>> > Thank you,
>> >
>> > Cory
>> >
>> > -----Original Message-----
>> > From: Rob Godfrey [mailto:rob.j.godfrey@gmail.com]
>> > Sent: Tuesday, August 26, 2014 9:40 AM
>> > To: users@qpid.apache.org
>> > Subject: Re: Experiences with Qpid AMQP 1.0 JMS client in production
>> >
>> > Hi Cory,
>> >
>> > On 26 August 2014 16:25, Adams, Cory <co...@paypal.com.invalid>
>> wrote:
>> >
>> > > Hi Rob,
>> > >
>> > > We are considering the JMS AMQP 1.0 client to be of high importance
>> > > and central to the success of our project. We have found that the
>> > > Qpid jms amqp 1.0 was indeed slow from a performance perspective.
>> > >
>> > >
>> > Can you give some details on the slowness - both the observed
>> > performance and the usage pattern. As I think Robbie pointed out in
>> > the other thread it's important to make sure that we are comparing
>> > like with like (for instance by default the JMS 1.0 client uses
>> > synchronous publishing, whereas the 0-x client publishes
>> > asynchronously... the former will always be a
>> > *lot* slower than the latter, but each client can be configured to use
>> > either mode - arguably the 1.0 client is correctly implementing the
>> > JMS spec by default, whereas the 0.x client is playing a bit fast and
>> > loose :-) ).
>> >
>> > In general I might expect the JMS 1.0 client to be slower because
>> > we've really not tuned it yet... but not orders of magnitude slower...
>> > and in persistent messaging the client should not be the critical path.
>> >
>> > Is there a timeline for shifting work toward the jms amqp 1.0
>> > > implementation on Proton?
>> > >
>> > >
>> > Robbie Gemmell is leading the work on the the new client - he would be
>> > in a better position to give dates.
>> >
>> > Hope that helps,
>> > Rob
>> >
>> > Thank you,
>> > >
>> > > Cory
>> > >
>> > > -----Original Message-----
>> > > From: Rob Godfrey [mailto:rob.j.godfrey@gmail.com]
>> > > Sent: Tuesday, August 26, 2014 3:40 AM
>> > > To: users@qpid.apache.org
>> > > Subject: Re: Experiences with Qpid AMQP 1.0 JMS client in production
>> > >
>> > > Hi Erik,
>> > >
>> > > I'm pretty sure there are people using the JMS 1.0 client in
>> > > production, as it is the client that Microsoft points users of their
>> > > Azure Service Bus offering to if they want to connect using Java
>> > > applications. I'm not sure how many of these users are subscribed
>> > > to
>> > this list however.
>> > >
>> > > In terms of the client itself, it's obviously less mature than the
>> > > 0-8/9/-9-1/-10 client (though almost definitionally it's as mature
>> > > as that client was when that client was the same age :-) ), and
>> > > doesn't have some of the features that the older client does (such
>> > > as automatic failover support). Moreover the JMS AMQP 1.0 client
>> > > was written before the Proton effort at a single AMQP 1.0 protocol
>> > > engine was started - and as a result we are aiming to eventually
>> > > replace the current JMS 1.0 client with one that is built around
>> > > Proton so that overall our AMQP 1.0 effort is easier to maintain
>> > > (Robbie Gemmell is leading this) . Until that work is completed
>> > > we'll still try to address any issues that arise (there are a number
>> > > of fixes for the JMS
>> > > 1.0 client in the upcoming 0.30 release), and also look at
>> > > introducing new features where they are in line with the work on the
>> > > standardised JMS mapping to AMQP that is going on at OASIS. By
>> > > keeping to standard JMS and the OASIS mapping there should be
>> > > minimal impact in moving from the current JMS AMQP 1.0 client to the
>> > > one based on Proton when it
>> > arrives.
>> > >
>> > > As was mentioned in another thread, the JMS AMQP 1.0 client has
>> > > certainly not been tuned for performance, so if you are looking to
>> > > send millions of message per second or guarantee nanosecond latency,
>> > > then it may not be for you. Overall all I can really say is that
>> > > you should test it to see if it meets your particular functional and
>> > non-functional requirements.
>> > >
>> > > Hope this helps,
>> > > Rob
>> > >
>> > >
>> > > On 26 August 2014 08:17, Erik Aschenbrenner <ea...@icubic.de>
>> wrote:
>> > >
>> > > > Dear Qpid users,
>> > > >
>> > > > so nobody has experiences with Qpid AMQP 1.0 JMS client in
>> > > > production so far?
>> > > >
>> > > > Regards,
>> > > > Erik
>> > > >
>> > > >
>> > > >
>> > > > --
>> > > > View this message in context:
>> > > > http://qpid.2158936.n2.nabble.com/Experiences-with-Qpid-AMQP-1-0-J
>> > > > MS -c lient-in-production-tp7611393p7612537.html
>> > > > Sent from the Apache Qpid users mailing list archive at Nabble.com.
>> > > >
>> > > > ------------------------------------------------------------------
>> > > > --
>> > > > - To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org For
>> > > > additional commands, e-mail: users-help@qpid.apache.org
>> > > >
>> > > >
>> > >
>> > > --------------------------------------------------------------------
>> > > - To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org For
>> > > additional commands, e-mail: users-help@qpid.apache.org
>> > >
>> > >
>> >
>>
>
>
Re: Experiences with Qpid AMQP 1.0 JMS client in production
Posted by Rob Godfrey <ro...@gmail.com>.
On 27 August 2014 22:52, Adams, Cory <co...@paypal.com.invalid> wrote:
> Rob,
>
> That did make a huge difference.
>
Glad to hear it!
>
> One question though - I tried the system property route by setting a -D
> arg (-Dqpid.sync_publish=false) but the client did not pick up the
> behavior. It did work with the amqp url ?sync-publish=false. Why is the
> system property being ignored?
>
>
I'll have to look into that - to be honest I just read the code and looked
at what it should be doing... I'll give it a test in the (European)
morning, and if there's something broken there try to get a fix in for the
0.30 release.
Cheers,
Rob
> This is for the 0.28 qpid-amqp-1-0-client
>
> Thank you for the suggestion,
>
> Cory
>
> -----Original Message-----
> From: Rob Godfrey [mailto:rob.j.godfrey@gmail.com]
> Sent: Tuesday, August 26, 2014 9:59 AM
> To: users@qpid.apache.org
> Subject: Re: Experiences with Qpid AMQP 1.0 JMS client in production
>
> So, first thing to make sure would be to make sure either both clients are
> in synchronous publish mode, or both in async... it makes a *huge*
> difference. (To turn off synchronous publish on the 1.0 client you can
> either set the system property "qpid.sync_publish" to false, or add the
> connection url argument sync-publish=false).
>
> We'd also need to look at how much of any performance difference is down
> to the client and how much to the broker... I see Gordon has already
> replied saying that he's made changes broker side on the performance of the
> C++ broker... I think it's probably also true that the Java Broker
> performance for 1.0 will be lower simply because we've not spent the time
> tuning it yet. Hopefully once we've got a few scenarios like yours we can
> start to look at tuning for the use-cases our users care about.
>
> Cheers,
> Rob
>
>
> On 26 August 2014 16:50, Adams, Cory <co...@paypal.com.invalid> wrote:
>
> > Hi Rob,
> >
> > I will pickup the test scenario later today and provide details. We
> > were doing simple bulk message sending to a queue with an asynch
> > listener and then comparing that to the throughput using the swiftmq
> > driver. This was against the qpid c++ broker.
> >
> > Thank you,
> >
> > Cory
> >
> > -----Original Message-----
> > From: Rob Godfrey [mailto:rob.j.godfrey@gmail.com]
> > Sent: Tuesday, August 26, 2014 9:40 AM
> > To: users@qpid.apache.org
> > Subject: Re: Experiences with Qpid AMQP 1.0 JMS client in production
> >
> > Hi Cory,
> >
> > On 26 August 2014 16:25, Adams, Cory <co...@paypal.com.invalid> wrote:
> >
> > > Hi Rob,
> > >
> > > We are considering the JMS AMQP 1.0 client to be of high importance
> > > and central to the success of our project. We have found that the
> > > Qpid jms amqp 1.0 was indeed slow from a performance perspective.
> > >
> > >
> > Can you give some details on the slowness - both the observed
> > performance and the usage pattern. As I think Robbie pointed out in
> > the other thread it's important to make sure that we are comparing
> > like with like (for instance by default the JMS 1.0 client uses
> > synchronous publishing, whereas the 0-x client publishes
> > asynchronously... the former will always be a
> > *lot* slower than the latter, but each client can be configured to use
> > either mode - arguably the 1.0 client is correctly implementing the
> > JMS spec by default, whereas the 0.x client is playing a bit fast and
> > loose :-) ).
> >
> > In general I might expect the JMS 1.0 client to be slower because
> > we've really not tuned it yet... but not orders of magnitude slower...
> > and in persistent messaging the client should not be the critical path.
> >
> > Is there a timeline for shifting work toward the jms amqp 1.0
> > > implementation on Proton?
> > >
> > >
> > Robbie Gemmell is leading the work on the the new client - he would be
> > in a better position to give dates.
> >
> > Hope that helps,
> > Rob
> >
> > Thank you,
> > >
> > > Cory
> > >
> > > -----Original Message-----
> > > From: Rob Godfrey [mailto:rob.j.godfrey@gmail.com]
> > > Sent: Tuesday, August 26, 2014 3:40 AM
> > > To: users@qpid.apache.org
> > > Subject: Re: Experiences with Qpid AMQP 1.0 JMS client in production
> > >
> > > Hi Erik,
> > >
> > > I'm pretty sure there are people using the JMS 1.0 client in
> > > production, as it is the client that Microsoft points users of their
> > > Azure Service Bus offering to if they want to connect using Java
> > > applications. I'm not sure how many of these users are subscribed
> > > to
> > this list however.
> > >
> > > In terms of the client itself, it's obviously less mature than the
> > > 0-8/9/-9-1/-10 client (though almost definitionally it's as mature
> > > as that client was when that client was the same age :-) ), and
> > > doesn't have some of the features that the older client does (such
> > > as automatic failover support). Moreover the JMS AMQP 1.0 client
> > > was written before the Proton effort at a single AMQP 1.0 protocol
> > > engine was started - and as a result we are aiming to eventually
> > > replace the current JMS 1.0 client with one that is built around
> > > Proton so that overall our AMQP 1.0 effort is easier to maintain
> > > (Robbie Gemmell is leading this) . Until that work is completed
> > > we'll still try to address any issues that arise (there are a number
> > > of fixes for the JMS
> > > 1.0 client in the upcoming 0.30 release), and also look at
> > > introducing new features where they are in line with the work on the
> > > standardised JMS mapping to AMQP that is going on at OASIS. By
> > > keeping to standard JMS and the OASIS mapping there should be
> > > minimal impact in moving from the current JMS AMQP 1.0 client to the
> > > one based on Proton when it
> > arrives.
> > >
> > > As was mentioned in another thread, the JMS AMQP 1.0 client has
> > > certainly not been tuned for performance, so if you are looking to
> > > send millions of message per second or guarantee nanosecond latency,
> > > then it may not be for you. Overall all I can really say is that
> > > you should test it to see if it meets your particular functional and
> > non-functional requirements.
> > >
> > > Hope this helps,
> > > Rob
> > >
> > >
> > > On 26 August 2014 08:17, Erik Aschenbrenner <ea...@icubic.de>
> wrote:
> > >
> > > > Dear Qpid users,
> > > >
> > > > so nobody has experiences with Qpid AMQP 1.0 JMS client in
> > > > production so far?
> > > >
> > > > Regards,
> > > > Erik
> > > >
> > > >
> > > >
> > > > --
> > > > View this message in context:
> > > > http://qpid.2158936.n2.nabble.com/Experiences-with-Qpid-AMQP-1-0-J
> > > > MS -c lient-in-production-tp7611393p7612537.html
> > > > Sent from the Apache Qpid users mailing list archive at Nabble.com.
> > > >
> > > > ------------------------------------------------------------------
> > > > --
> > > > - To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org For
> > > > additional commands, e-mail: users-help@qpid.apache.org
> > > >
> > > >
> > >
> > > --------------------------------------------------------------------
> > > - To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org For
> > > additional commands, e-mail: users-help@qpid.apache.org
> > >
> > >
> >
>
RE: Experiences with Qpid AMQP 1.0 JMS client in production
Posted by "Adams, Cory" <co...@paypal.com.INVALID>.
Rob,
That did make a huge difference.
One question though - I tried the system property route by setting a -D arg (-Dqpid.sync_publish=false) but the client did not pick up the behavior. It did work with the amqp url ?sync-publish=false. Why is the system property being ignored?
This is for the 0.28 qpid-amqp-1-0-client
Thank you for the suggestion,
Cory
-----Original Message-----
From: Rob Godfrey [mailto:rob.j.godfrey@gmail.com]
Sent: Tuesday, August 26, 2014 9:59 AM
To: users@qpid.apache.org
Subject: Re: Experiences with Qpid AMQP 1.0 JMS client in production
So, first thing to make sure would be to make sure either both clients are in synchronous publish mode, or both in async... it makes a *huge* difference. (To turn off synchronous publish on the 1.0 client you can either set the system property "qpid.sync_publish" to false, or add the connection url argument sync-publish=false).
We'd also need to look at how much of any performance difference is down to the client and how much to the broker... I see Gordon has already replied saying that he's made changes broker side on the performance of the C++ broker... I think it's probably also true that the Java Broker performance for 1.0 will be lower simply because we've not spent the time tuning it yet. Hopefully once we've got a few scenarios like yours we can start to look at tuning for the use-cases our users care about.
Cheers,
Rob
On 26 August 2014 16:50, Adams, Cory <co...@paypal.com.invalid> wrote:
> Hi Rob,
>
> I will pickup the test scenario later today and provide details. We
> were doing simple bulk message sending to a queue with an asynch
> listener and then comparing that to the throughput using the swiftmq
> driver. This was against the qpid c++ broker.
>
> Thank you,
>
> Cory
>
> -----Original Message-----
> From: Rob Godfrey [mailto:rob.j.godfrey@gmail.com]
> Sent: Tuesday, August 26, 2014 9:40 AM
> To: users@qpid.apache.org
> Subject: Re: Experiences with Qpid AMQP 1.0 JMS client in production
>
> Hi Cory,
>
> On 26 August 2014 16:25, Adams, Cory <co...@paypal.com.invalid> wrote:
>
> > Hi Rob,
> >
> > We are considering the JMS AMQP 1.0 client to be of high importance
> > and central to the success of our project. We have found that the
> > Qpid jms amqp 1.0 was indeed slow from a performance perspective.
> >
> >
> Can you give some details on the slowness - both the observed
> performance and the usage pattern. As I think Robbie pointed out in
> the other thread it's important to make sure that we are comparing
> like with like (for instance by default the JMS 1.0 client uses
> synchronous publishing, whereas the 0-x client publishes
> asynchronously... the former will always be a
> *lot* slower than the latter, but each client can be configured to use
> either mode - arguably the 1.0 client is correctly implementing the
> JMS spec by default, whereas the 0.x client is playing a bit fast and
> loose :-) ).
>
> In general I might expect the JMS 1.0 client to be slower because
> we've really not tuned it yet... but not orders of magnitude slower...
> and in persistent messaging the client should not be the critical path.
>
> Is there a timeline for shifting work toward the jms amqp 1.0
> > implementation on Proton?
> >
> >
> Robbie Gemmell is leading the work on the the new client - he would be
> in a better position to give dates.
>
> Hope that helps,
> Rob
>
> Thank you,
> >
> > Cory
> >
> > -----Original Message-----
> > From: Rob Godfrey [mailto:rob.j.godfrey@gmail.com]
> > Sent: Tuesday, August 26, 2014 3:40 AM
> > To: users@qpid.apache.org
> > Subject: Re: Experiences with Qpid AMQP 1.0 JMS client in production
> >
> > Hi Erik,
> >
> > I'm pretty sure there are people using the JMS 1.0 client in
> > production, as it is the client that Microsoft points users of their
> > Azure Service Bus offering to if they want to connect using Java
> > applications. I'm not sure how many of these users are subscribed
> > to
> this list however.
> >
> > In terms of the client itself, it's obviously less mature than the
> > 0-8/9/-9-1/-10 client (though almost definitionally it's as mature
> > as that client was when that client was the same age :-) ), and
> > doesn't have some of the features that the older client does (such
> > as automatic failover support). Moreover the JMS AMQP 1.0 client
> > was written before the Proton effort at a single AMQP 1.0 protocol
> > engine was started - and as a result we are aiming to eventually
> > replace the current JMS 1.0 client with one that is built around
> > Proton so that overall our AMQP 1.0 effort is easier to maintain
> > (Robbie Gemmell is leading this) . Until that work is completed
> > we'll still try to address any issues that arise (there are a number
> > of fixes for the JMS
> > 1.0 client in the upcoming 0.30 release), and also look at
> > introducing new features where they are in line with the work on the
> > standardised JMS mapping to AMQP that is going on at OASIS. By
> > keeping to standard JMS and the OASIS mapping there should be
> > minimal impact in moving from the current JMS AMQP 1.0 client to the
> > one based on Proton when it
> arrives.
> >
> > As was mentioned in another thread, the JMS AMQP 1.0 client has
> > certainly not been tuned for performance, so if you are looking to
> > send millions of message per second or guarantee nanosecond latency,
> > then it may not be for you. Overall all I can really say is that
> > you should test it to see if it meets your particular functional and
> non-functional requirements.
> >
> > Hope this helps,
> > Rob
> >
> >
> > On 26 August 2014 08:17, Erik Aschenbrenner <ea...@icubic.de> wrote:
> >
> > > Dear Qpid users,
> > >
> > > so nobody has experiences with Qpid AMQP 1.0 JMS client in
> > > production so far?
> > >
> > > Regards,
> > > Erik
> > >
> > >
> > >
> > > --
> > > View this message in context:
> > > http://qpid.2158936.n2.nabble.com/Experiences-with-Qpid-AMQP-1-0-J
> > > MS -c lient-in-production-tp7611393p7612537.html
> > > Sent from the Apache Qpid users mailing list archive at Nabble.com.
> > >
> > > ------------------------------------------------------------------
> > > --
> > > - To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org For
> > > additional commands, e-mail: users-help@qpid.apache.org
> > >
> > >
> >
> > --------------------------------------------------------------------
> > - To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org For
> > additional commands, e-mail: users-help@qpid.apache.org
> >
> >
>
Re: Experiences with Qpid AMQP 1.0 JMS client in production
Posted by Rob Godfrey <ro...@gmail.com>.
So, first thing to make sure would be to make sure either both clients are
in synchronous publish mode, or both in async... it makes a *huge*
difference. (To turn off synchronous publish on the 1.0 client you can
either set the system property "qpid.sync_publish" to false, or add the
connection url argument sync-publish=false).
We'd also need to look at how much of any performance difference is down to
the client and how much to the broker... I see Gordon has already replied
saying that he's made changes broker side on the performance of the C++
broker... I think it's probably also true that the Java Broker performance
for 1.0 will be lower simply because we've not spent the time tuning it
yet. Hopefully once we've got a few scenarios like yours we can start to
look at tuning for the use-cases our users care about.
Cheers,
Rob
On 26 August 2014 16:50, Adams, Cory <co...@paypal.com.invalid> wrote:
> Hi Rob,
>
> I will pickup the test scenario later today and provide details. We were
> doing simple bulk message sending to a queue with an asynch listener and
> then comparing that to the throughput using the swiftmq driver. This was
> against the qpid c++ broker.
>
> Thank you,
>
> Cory
>
> -----Original Message-----
> From: Rob Godfrey [mailto:rob.j.godfrey@gmail.com]
> Sent: Tuesday, August 26, 2014 9:40 AM
> To: users@qpid.apache.org
> Subject: Re: Experiences with Qpid AMQP 1.0 JMS client in production
>
> Hi Cory,
>
> On 26 August 2014 16:25, Adams, Cory <co...@paypal.com.invalid> wrote:
>
> > Hi Rob,
> >
> > We are considering the JMS AMQP 1.0 client to be of high importance
> > and central to the success of our project. We have found that the
> > Qpid jms amqp 1.0 was indeed slow from a performance perspective.
> >
> >
> Can you give some details on the slowness - both the observed performance
> and the usage pattern. As I think Robbie pointed out in the other thread
> it's important to make sure that we are comparing like with like (for
> instance by default the JMS 1.0 client uses synchronous publishing, whereas
> the 0-x client publishes asynchronously... the former will always be a
> *lot* slower than the latter, but each client can be configured to use
> either mode - arguably the 1.0 client is correctly implementing the JMS
> spec by default, whereas the 0.x client is playing a bit fast and loose :-)
> ).
>
> In general I might expect the JMS 1.0 client to be slower because we've
> really not tuned it yet... but not orders of magnitude slower... and in
> persistent messaging the client should not be the critical path.
>
> Is there a timeline for shifting work toward the jms amqp 1.0
> > implementation on Proton?
> >
> >
> Robbie Gemmell is leading the work on the the new client - he would be in
> a better position to give dates.
>
> Hope that helps,
> Rob
>
> Thank you,
> >
> > Cory
> >
> > -----Original Message-----
> > From: Rob Godfrey [mailto:rob.j.godfrey@gmail.com]
> > Sent: Tuesday, August 26, 2014 3:40 AM
> > To: users@qpid.apache.org
> > Subject: Re: Experiences with Qpid AMQP 1.0 JMS client in production
> >
> > Hi Erik,
> >
> > I'm pretty sure there are people using the JMS 1.0 client in
> > production, as it is the client that Microsoft points users of their
> > Azure Service Bus offering to if they want to connect using Java
> > applications. I'm not sure how many of these users are subscribed to
> this list however.
> >
> > In terms of the client itself, it's obviously less mature than the
> > 0-8/9/-9-1/-10 client (though almost definitionally it's as mature as
> > that client was when that client was the same age :-) ), and doesn't
> > have some of the features that the older client does (such as
> > automatic failover support). Moreover the JMS AMQP 1.0 client was
> > written before the Proton effort at a single AMQP 1.0 protocol engine
> > was started - and as a result we are aiming to eventually replace the
> > current JMS 1.0 client with one that is built around Proton so that
> > overall our AMQP 1.0 effort is easier to maintain (Robbie Gemmell is
> > leading this) . Until that work is completed we'll still try to
> > address any issues that arise (there are a number of fixes for the JMS
> > 1.0 client in the upcoming 0.30 release), and also look at introducing
> > new features where they are in line with the work on the standardised
> > JMS mapping to AMQP that is going on at OASIS. By keeping to standard
> > JMS and the OASIS mapping there should be minimal impact in moving
> > from the current JMS AMQP 1.0 client to the one based on Proton when it
> arrives.
> >
> > As was mentioned in another thread, the JMS AMQP 1.0 client has
> > certainly not been tuned for performance, so if you are looking to
> > send millions of message per second or guarantee nanosecond latency,
> > then it may not be for you. Overall all I can really say is that you
> > should test it to see if it meets your particular functional and
> non-functional requirements.
> >
> > Hope this helps,
> > Rob
> >
> >
> > On 26 August 2014 08:17, Erik Aschenbrenner <ea...@icubic.de> wrote:
> >
> > > Dear Qpid users,
> > >
> > > so nobody has experiences with Qpid AMQP 1.0 JMS client in
> > > production so far?
> > >
> > > Regards,
> > > Erik
> > >
> > >
> > >
> > > --
> > > View this message in context:
> > > http://qpid.2158936.n2.nabble.com/Experiences-with-Qpid-AMQP-1-0-JMS
> > > -c lient-in-production-tp7611393p7612537.html
> > > Sent from the Apache Qpid users mailing list archive at Nabble.com.
> > >
> > > --------------------------------------------------------------------
> > > - To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org For
> > > additional commands, e-mail: users-help@qpid.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org For
> > additional commands, e-mail: users-help@qpid.apache.org
> >
> >
>
Re: Experiences with Qpid AMQP 1.0 JMS client in production
Posted by Gordon Sim <gs...@redhat.com>.
On 08/26/2014 03:50 PM, Adams, Cory wrote:
> I will pickup the test scenario later today and provide details. We
> were doing simple bulk message sending to a queue with an asynch
> listener and then comparing that to the throughput using the swiftmq
> driver. This was against the qpid c++ broker.
Just fyi on that: I've very recently made some changes on trunk that
improve the throughput of the c++ broker for AMQP 1.0 in my testing
(using the c++ client).
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
RE: Experiences with Qpid AMQP 1.0 JMS client in production
Posted by "Adams, Cory" <co...@paypal.com.INVALID>.
Hi Rob,
I will pickup the test scenario later today and provide details. We were doing simple bulk message sending to a queue with an asynch listener and then comparing that to the throughput using the swiftmq driver. This was against the qpid c++ broker.
Thank you,
Cory
-----Original Message-----
From: Rob Godfrey [mailto:rob.j.godfrey@gmail.com]
Sent: Tuesday, August 26, 2014 9:40 AM
To: users@qpid.apache.org
Subject: Re: Experiences with Qpid AMQP 1.0 JMS client in production
Hi Cory,
On 26 August 2014 16:25, Adams, Cory <co...@paypal.com.invalid> wrote:
> Hi Rob,
>
> We are considering the JMS AMQP 1.0 client to be of high importance
> and central to the success of our project. We have found that the
> Qpid jms amqp 1.0 was indeed slow from a performance perspective.
>
>
Can you give some details on the slowness - both the observed performance and the usage pattern. As I think Robbie pointed out in the other thread it's important to make sure that we are comparing like with like (for instance by default the JMS 1.0 client uses synchronous publishing, whereas the 0-x client publishes asynchronously... the former will always be a
*lot* slower than the latter, but each client can be configured to use either mode - arguably the 1.0 client is correctly implementing the JMS spec by default, whereas the 0.x client is playing a bit fast and loose :-) ).
In general I might expect the JMS 1.0 client to be slower because we've really not tuned it yet... but not orders of magnitude slower... and in persistent messaging the client should not be the critical path.
Is there a timeline for shifting work toward the jms amqp 1.0
> implementation on Proton?
>
>
Robbie Gemmell is leading the work on the the new client - he would be in a better position to give dates.
Hope that helps,
Rob
Thank you,
>
> Cory
>
> -----Original Message-----
> From: Rob Godfrey [mailto:rob.j.godfrey@gmail.com]
> Sent: Tuesday, August 26, 2014 3:40 AM
> To: users@qpid.apache.org
> Subject: Re: Experiences with Qpid AMQP 1.0 JMS client in production
>
> Hi Erik,
>
> I'm pretty sure there are people using the JMS 1.0 client in
> production, as it is the client that Microsoft points users of their
> Azure Service Bus offering to if they want to connect using Java
> applications. I'm not sure how many of these users are subscribed to this list however.
>
> In terms of the client itself, it's obviously less mature than the
> 0-8/9/-9-1/-10 client (though almost definitionally it's as mature as
> that client was when that client was the same age :-) ), and doesn't
> have some of the features that the older client does (such as
> automatic failover support). Moreover the JMS AMQP 1.0 client was
> written before the Proton effort at a single AMQP 1.0 protocol engine
> was started - and as a result we are aiming to eventually replace the
> current JMS 1.0 client with one that is built around Proton so that
> overall our AMQP 1.0 effort is easier to maintain (Robbie Gemmell is
> leading this) . Until that work is completed we'll still try to
> address any issues that arise (there are a number of fixes for the JMS
> 1.0 client in the upcoming 0.30 release), and also look at introducing
> new features where they are in line with the work on the standardised
> JMS mapping to AMQP that is going on at OASIS. By keeping to standard
> JMS and the OASIS mapping there should be minimal impact in moving
> from the current JMS AMQP 1.0 client to the one based on Proton when it arrives.
>
> As was mentioned in another thread, the JMS AMQP 1.0 client has
> certainly not been tuned for performance, so if you are looking to
> send millions of message per second or guarantee nanosecond latency,
> then it may not be for you. Overall all I can really say is that you
> should test it to see if it meets your particular functional and non-functional requirements.
>
> Hope this helps,
> Rob
>
>
> On 26 August 2014 08:17, Erik Aschenbrenner <ea...@icubic.de> wrote:
>
> > Dear Qpid users,
> >
> > so nobody has experiences with Qpid AMQP 1.0 JMS client in
> > production so far?
> >
> > Regards,
> > Erik
> >
> >
> >
> > --
> > View this message in context:
> > http://qpid.2158936.n2.nabble.com/Experiences-with-Qpid-AMQP-1-0-JMS
> > -c lient-in-production-tp7611393p7612537.html
> > Sent from the Apache Qpid users mailing list archive at Nabble.com.
> >
> > --------------------------------------------------------------------
> > - To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org For
> > additional commands, e-mail: users-help@qpid.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org For
> additional commands, e-mail: users-help@qpid.apache.org
>
>
Re: Experiences with Qpid AMQP 1.0 JMS client in production
Posted by Rob Godfrey <ro...@gmail.com>.
Hi Cory,
On 26 August 2014 16:25, Adams, Cory <co...@paypal.com.invalid> wrote:
> Hi Rob,
>
> We are considering the JMS AMQP 1.0 client to be of high importance and
> central to the success of our project. We have found that the Qpid jms
> amqp 1.0 was indeed slow from a performance perspective.
>
>
Can you give some details on the slowness - both the observed performance
and the usage pattern. As I think Robbie pointed out in the other thread
it's important to make sure that we are comparing like with like (for
instance by default the JMS 1.0 client uses synchronous publishing, whereas
the 0-x client publishes asynchronously... the former will always be a
*lot* slower than the latter, but each client can be configured to use
either mode - arguably the 1.0 client is correctly implementing the JMS
spec by default, whereas the 0.x client is playing a bit fast and loose :-)
).
In general I might expect the JMS 1.0 client to be slower because we've
really not tuned it yet... but not orders of magnitude slower... and in
persistent messaging the client should not be the critical path.
Is there a timeline for shifting work toward the jms amqp 1.0
> implementation on Proton?
>
>
Robbie Gemmell is leading the work on the the new client - he would be in a
better position to give dates.
Hope that helps,
Rob
Thank you,
>
> Cory
>
> -----Original Message-----
> From: Rob Godfrey [mailto:rob.j.godfrey@gmail.com]
> Sent: Tuesday, August 26, 2014 3:40 AM
> To: users@qpid.apache.org
> Subject: Re: Experiences with Qpid AMQP 1.0 JMS client in production
>
> Hi Erik,
>
> I'm pretty sure there are people using the JMS 1.0 client in production,
> as it is the client that Microsoft points users of their Azure Service Bus
> offering to if they want to connect using Java applications. I'm not sure
> how many of these users are subscribed to this list however.
>
> In terms of the client itself, it's obviously less mature than the
> 0-8/9/-9-1/-10 client (though almost definitionally it's as mature as
> that client was when that client was the same age :-) ), and doesn't have
> some of the features that the older client does (such as automatic failover
> support). Moreover the JMS AMQP 1.0 client was written before the Proton
> effort at a single AMQP 1.0 protocol engine was started - and as a result
> we are aiming to eventually replace the current JMS 1.0 client with one
> that is built around Proton so that overall our AMQP 1.0 effort is easier
> to maintain (Robbie Gemmell is leading this) . Until that work is completed
> we'll still try to address any issues that arise (there are a number of
> fixes for the JMS 1.0 client in the upcoming 0.30 release), and also look
> at introducing new features where they are in line with the work on the
> standardised JMS mapping to AMQP that is going on at OASIS. By keeping to
> standard JMS and the OASIS mapping there should be minimal impact in moving
> from the current JMS AMQP 1.0 client to the one based on Proton when it
> arrives.
>
> As was mentioned in another thread, the JMS AMQP 1.0 client has certainly
> not been tuned for performance, so if you are looking to send millions of
> message per second or guarantee nanosecond latency, then it may not be for
> you. Overall all I can really say is that you should test it to see if it
> meets your particular functional and non-functional requirements.
>
> Hope this helps,
> Rob
>
>
> On 26 August 2014 08:17, Erik Aschenbrenner <ea...@icubic.de> wrote:
>
> > Dear Qpid users,
> >
> > so nobody has experiences with Qpid AMQP 1.0 JMS client in production
> > so far?
> >
> > Regards,
> > Erik
> >
> >
> >
> > --
> > View this message in context:
> > http://qpid.2158936.n2.nabble.com/Experiences-with-Qpid-AMQP-1-0-JMS-c
> > lient-in-production-tp7611393p7612537.html
> > Sent from the Apache Qpid users mailing list archive at Nabble.com.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org For
> > additional commands, e-mail: users-help@qpid.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
RE: Experiences with Qpid AMQP 1.0 JMS client in production
Posted by "Adams, Cory" <co...@paypal.com.INVALID>.
Hi Rob,
We are considering the JMS AMQP 1.0 client to be of high importance and central to the success of our project. We have found that the Qpid jms amqp 1.0 was indeed slow from a performance perspective.
Is there a timeline for shifting work toward the jms amqp 1.0 implementation on Proton?
Thank you,
Cory
-----Original Message-----
From: Rob Godfrey [mailto:rob.j.godfrey@gmail.com]
Sent: Tuesday, August 26, 2014 3:40 AM
To: users@qpid.apache.org
Subject: Re: Experiences with Qpid AMQP 1.0 JMS client in production
Hi Erik,
I'm pretty sure there are people using the JMS 1.0 client in production, as it is the client that Microsoft points users of their Azure Service Bus offering to if they want to connect using Java applications. I'm not sure how many of these users are subscribed to this list however.
In terms of the client itself, it's obviously less mature than the
0-8/9/-9-1/-10 client (though almost definitionally it's as mature as that client was when that client was the same age :-) ), and doesn't have some of the features that the older client does (such as automatic failover support). Moreover the JMS AMQP 1.0 client was written before the Proton effort at a single AMQP 1.0 protocol engine was started - and as a result we are aiming to eventually replace the current JMS 1.0 client with one that is built around Proton so that overall our AMQP 1.0 effort is easier to maintain (Robbie Gemmell is leading this) . Until that work is completed we'll still try to address any issues that arise (there are a number of fixes for the JMS 1.0 client in the upcoming 0.30 release), and also look at introducing new features where they are in line with the work on the standardised JMS mapping to AMQP that is going on at OASIS. By keeping to standard JMS and the OASIS mapping there should be minimal impact in moving from the current JMS AMQP 1.0 client to the one based on Proton when it arrives.
As was mentioned in another thread, the JMS AMQP 1.0 client has certainly not been tuned for performance, so if you are looking to send millions of message per second or guarantee nanosecond latency, then it may not be for you. Overall all I can really say is that you should test it to see if it meets your particular functional and non-functional requirements.
Hope this helps,
Rob
On 26 August 2014 08:17, Erik Aschenbrenner <ea...@icubic.de> wrote:
> Dear Qpid users,
>
> so nobody has experiences with Qpid AMQP 1.0 JMS client in production
> so far?
>
> Regards,
> Erik
>
>
>
> --
> View this message in context:
> http://qpid.2158936.n2.nabble.com/Experiences-with-Qpid-AMQP-1-0-JMS-c
> lient-in-production-tp7611393p7612537.html
> Sent from the Apache Qpid users mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org For
> additional commands, e-mail: users-help@qpid.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Experiences with Qpid AMQP 1.0 JMS client in production
Posted by Erik Aschenbrenner <ea...@icubic.de>.
Hi Rob,
thank you for your answers.
I will share my experiences when I'm able to test against the AMQP 1.0
broker to which I have to connect.
Do you have a plan when the proton based JMS client will be ready?
Kind Regards,
Erik
--
View this message in context: http://qpid.2158936.n2.nabble.com/Experiences-with-Qpid-AMQP-1-0-JMS-client-in-production-tp7611393p7612553.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Experiences with Qpid AMQP 1.0 JMS client in production
Posted by Rob Godfrey <ro...@gmail.com>.
Hi Erik,
I'm pretty sure there are people using the JMS 1.0 client in production, as
it is the client that Microsoft points users of their Azure Service Bus
offering to if they want to connect using Java applications. I'm not sure
how many of these users are subscribed to this list however.
In terms of the client itself, it's obviously less mature than the
0-8/9/-9-1/-10 client (though almost definitionally it's as mature as that
client was when that client was the same age :-) ), and doesn't have some
of the features that the older client does (such as automatic failover
support). Moreover the JMS AMQP 1.0 client was written before the Proton
effort at a single AMQP 1.0 protocol engine was started - and as a result
we are aiming to eventually replace the current JMS 1.0 client with one
that is built around Proton so that overall our AMQP 1.0 effort is easier
to maintain (Robbie Gemmell is leading this) . Until that work is completed
we'll still try to address any issues that arise (there are a number of
fixes for the JMS 1.0 client in the upcoming 0.30 release), and also look
at introducing new features where they are in line with the work on the
standardised JMS mapping to AMQP that is going on at OASIS. By keeping to
standard JMS and the OASIS mapping there should be minimal impact in moving
from the current JMS AMQP 1.0 client to the one based on Proton when it
arrives.
As was mentioned in another thread, the JMS AMQP 1.0 client has certainly
not been tuned for performance, so if you are looking to send millions of
message per second or guarantee nanosecond latency, then it may not be for
you. Overall all I can really say is that you should test it to see if it
meets your particular functional and non-functional requirements.
Hope this helps,
Rob
On 26 August 2014 08:17, Erik Aschenbrenner <ea...@icubic.de> wrote:
> Dear Qpid users,
>
> so nobody has experiences with Qpid AMQP 1.0 JMS client in production so
> far?
>
> Regards,
> Erik
>
>
>
> --
> View this message in context:
> http://qpid.2158936.n2.nabble.com/Experiences-with-Qpid-AMQP-1-0-JMS-client-in-production-tp7611393p7612537.html
> Sent from the Apache Qpid users mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
Re: Experiences with Qpid AMQP 1.0 JMS client in production
Posted by Erik Aschenbrenner <ea...@icubic.de>.
Dear Qpid users,
so nobody has experiences with Qpid AMQP 1.0 JMS client in production so
far?
Regards,
Erik
--
View this message in context: http://qpid.2158936.n2.nabble.com/Experiences-with-Qpid-AMQP-1-0-JMS-client-in-production-tp7611393p7612537.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org