One important point to note is that the new address format I talked about in Qpid JMS client, will only be implemented in the 0-10 code path. It may or may not get implemented in the 0-8/0-9 code path as it may not have much benefit given that AMQP 1.0 is coming out sometime next year. Therefore you would not have the same features/flexibility I talked about when running against an 0-8/0-9 broker. Ex RabbitMQ. But I doubt there is much of an impact for most use cases. At least not the ones I have seen so far for Synapse.
But once AMQP 1.0 comes out, RabbitMQ and all other vendors will obviously support 1.0, so this is only a temporary issue. Rajith On Thu, Nov 26, 2009 at 2:43 PM, Rajith Attapattu <[email protected]> wrote: > On Thu, Nov 26, 2009 at 1:38 PM, Asanka Abeysinghe <[email protected]> wrote: >> Hi Rajith, >> Thank you for the detailed explanation, so it seems we don't have any >> functionality limitations by using JMS to bridge AMQP. > > For the most part no. 95% of the use cases could be met with using > pure JMS interfaces. > So far most of the client use cases we encountered were able to > satisfy with the JMS client. > Anytime we found it difficult, it was more due to the design issues in > the JMS client than anything else. > Based on those use cases we kept on improving the JMS client. > The other clients written in python, c++ (and eventually ruby) are > also moving towards protocol-version agnostic high level API's. > > However due to the limitations of the JMS API there will be use cases > that may not be able to satisfy effectively. > For example streaming large messages. (there are ways to get around > this but may not be as efficient though) > Also the JMS imposes a certain threading model in the client > implementation when doing message listeners. > There maybe use cases where you want a single thread to read from > subscriptions based on several sessions. > This is not possible with JMS unless we use receive() where the > semantics mandate it to be synchronous in nature with certain > guarantees that makes this method slow. > The motivation for the said use case is where you have a worker thread > pool and want to read messages as efficiently as possible from a bunch > of queues (spread across several sessions) where the number of > sessions is greater than the number of cores available for the > process. So having a thread per session may result in a lot of context > switching. > But these are specialized use cases. I don't know if Synapse has such > requirements. > > >> What about performance, do you think it will be same with JMS and a native >> AMQP java >> client ? > > There was also quite a bit of performance work done in the JMS client > to the extent the difference btw the JMS layer and lower layer is > negligible for most real business applications especially within the > context of something like Synapse. In artificial benchmarks the diff > is about 10k msg/sec. > >> And I like to know the motivation behind on writing the previous native AMQP >> code we had ? Was it due to limited support JMS on QPid ? > > Several reasons. > The JMS client had a few design issues that prevented it from making > full use of the protocol. > For example it wasn't possible to do declare/bind arguments or bind > the same queue with multiple binding keys. > Setting flow control or reliability guarantees on a per destination > basis was also not possible even at present. > This is being addressed now with the new address format. > So It took us some time to figure out the best way to allow such > support while using pure JMS interfaces. > > Another reason was performance. At the time the delta btw the native > and JMS layer was quite a bit. > But now most of those issues are addressed to an extent that it > doesn't really matter for most real business applications. > > Another reason was that I didn't know better at that time and had the > same questions that you raised. > I didn't have reasonable answers to those questions and at times had > the incorrect assumption that it was due to limitations of the JMS > API. > Then we found ways of addressing those concerns properly. > Now with the benefit of hindsight I realize that most of those > questions can be answered satisfactorily. > > Thanks for all these questions as the discussion will make it clear if > we would need an AMQP client or not. > I also urge you to think through the use cases for Synapse (as you > guys know them best) and see if any of my explanations doesn't fit or > doesn't answer them completely. > I think it's a worthwhile experiment to do that. We could also > document those cases so the end users know how best to leverage AMQP > support via Synapse. > >> Thx >> Asanka >> >> On Thu, Nov 26, 2009 at 9:18 PM, Rajith Attapattu <[email protected]> >> wrote: >>> >>> On Thu, Nov 26, 2009 at 4:31 AM, Asanka Abeysinghe <[email protected]> >>> wrote: >>> > +1 for native AMQP transport, >>> > By bridging from JMS to AMQP is it possible to get the full advantage of >>> > AMQP specific features like exchanges, exchange types, routing keys, >>> > dynamic >>> > creation of queues etc ... ? >>> >>> Again Good question and one for the FAQ. >>> Even now the JMS client is flexible enough to take full advantage of >>> exchanges, exchange types, rk's and dynamic creation of queues. >>> The new addressing format is even more flexible as it permits lot more >>> options like flow control, reliability expectations, declare and bind >>> arguments, how and when queues should be created by the client (ex >>> never - centrally administered, producer-created by producer, >>> consumer-created by consumer) >>> (As an aside, it's worth noting that exchanges are not going to be >>> there in 1.0 ) >>> >>> If you need to create queues as part of business logic, you could >>> still use the createQueue()/createTopic() methods and pass in an >>> address string and get the same benefits mentioned above. >>> As I mentioned in my first email, one important development in AMQP >>> 1.0 is that management commands such as declare, bind , query queues >>> etc... are not part of the core protocol, but rather sent as messages >>> over the transport to a known admin/mgt service. The Qpid project's >>> QMF framework is aiming to follow that direction even from 0-10 by >>> allowing to perform management functions using pure message passing >>> (ex using Map messages) >>> >>> Does this sufficiently answer your all your questions? >>> If not please feel free to dig further and I am happy to answer any >>> questions you have. >>> >>> If you have specific use cases that would also help, as sometimes >>> discussing in abstract form is a bit difficult. >>> >>> Regards, >>> >>> Rajith >>> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
