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