qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Godfrey <rob.j.godf...@gmail.com>
Subject Re: Experiences with Qpid AMQP 1.0 JMS client in production
Date Thu, 28 Aug 2014 07:59:21 GMT
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 <rob.j.godfrey@gmail.com> wrote:

>
>
>
> On 27 August 2014 22:52, Adams, Cory <coadams@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 <coadams@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 <coadams@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 <easchenb@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
>> > >
>> > >
>> >
>>
>
>

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