On Thu, Nov 26, 2009 at 1:38 PM, Asanka Abeysinghe <asan...@wso2.com> 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 <rajit...@gmail.com> > wrote: >> >> On Thu, Nov 26, 2009 at 4:31 AM, Asanka Abeysinghe <asan...@wso2.com> >> 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 >> >> > - Asanka >> > >> > On Thu, Nov 26, 2009 at 10:34 AM, Ruwan Linton <ruwan.lin...@gmail.com> >> > wrote: >> >> >> >> +1 for developing a native AMQP transport. >> >> >> >> Thanks, >> >> Ruwan >> >> >> >> On Thu, Nov 26, 2009 at 9:52 AM, Hiranya Jayathilaka >> >> <hiranya...@gmail.com> wrote: >> >>> >> >>> Well personally I like the idea of Synapse having a native AMQP >> >>> implementation rather than having to access AMQP queues over JMS. Some >> >>> of >> >>> the prominent AMQP providers like RabbitMQ does not provide JMS and >> >>> JNDI >> >>> support at a satisfactory level. IMHO it is totally worth having this >> >>> transport - as an optional one of course. >> >>> >> >>> Thanks, >> >>> Hiranya >> >>> >> >>> On Wed, Nov 25, 2009 at 11:14 PM, Rajith Attapattu >> >>> <rajit...@gmail.com> >> >>> wrote: >> >>>> >> >>>> Hi Lahiru, >> >>>> >> >>>> I am afraid it's in an unusable state atm mainly due to my fault. >> >>>> I would also like to take this opportunity to discuss the continuity >> >>>> of the amqp transport. >> >>>> >> >>>> The motivation behind creating an AMQP specific transport instead of >> >>>> using it via the JMS transport was due to the perceived flexibility & >> >>>> performance achieved via a transport that is close to the protocol. >> >>>> >> >>>> However as Qpid gained more experience and myself having the >> >>>> privilege >> >>>> of working with customers and end users realized that the JMS >> >>>> implementation is lacking this flexibility more due to design issues >> >>>> than any real issue with the API itself. Over the last year or so we >> >>>> made significant improvements to the JMS client. >> >>>> The new address format that will be used by all the Qpid clients >> >>>> including JMS will be rich enough to tune protocol specifics via the >> >>>> javax.jms.Destination abstraction while allowing applications to use >> >>>> pure JMS without having to resort to a vendor specific low level API. >> >>>> Going forward management aspects such as having to create >> >>>> queues/exchanges dynamically could be done by sending a map message >> >>>> than invoking a protocol command. Infact in AMQP 1.0 management/admin >> >>>> work such as declaring queues are not protocol specific commands any >> >>>> more. They are achieved via sending messages to a known admin/mgt >> >>>> service within a container. >> >>>> >> >>>> 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 a real business application especially within the >> >>>> context of Synapse. In artificial benchmarks the diff is about 10k >> >>>> msg/sec. >> >>>> >> >>>> Therefore with the benefit of hindsight I feel that having an AMQP >> >>>> specific transport doesn't add anything significant over the well >> >>>> tested JMS transport that Synapse has. >> >>>> However before coming to a conclusion, it would be worthwhile to >> >>>> figure out all the use cases around AMQP with Synapse. >> >>>> Then we could document how they could be achieved via the JMS >> >>>> transport. >> >>>> If there are any use cases that cannot be reasonably met, then >> >>>> perhaps >> >>>> we could discuss about an AMQP specific transport. >> >>>> >> >>>> Regards, >> >>>> >> >>>> Rajith >> >>>> >> >>>> On Wed, Nov 25, 2009 at 9:22 AM, Lahiru Gunathilake >> >>>> <glah...@gmail.com> >> >>>> wrote: >> >>>> > Hi all, >> >>>> > >> >>>> > I like to do some work with synapse AMQP trasport and like to know >> >>>> > the >> >>>> > status of the trasport in current synapse code base. >> >>>> > >> >>>> > Regards >> >>>> > Lahiru >> >>>> > >> >>>> > -- >> >>>> > Apache Qpid, Worlds dominant messaging middleware..!!! >> >>>> > >> >>>> >> >>>> >> >>>> >> >>>> -- >> >>>> Regards, >> >>>> >> >>>> Rajith Attapattu >> >>>> Red Hat >> >>>> http://rajith.2rlabs.com/ >> >>>> >> >>>> --------------------------------------------------------------------- >> >>>> To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org >> >>>> For additional commands, e-mail: dev-h...@synapse.apache.org >> >>>> >> >>> >> >>> >> >>> >> >>> -- >> >>> Hiranya Jayathilaka >> >>> Software Engineer; >> >>> WSO2 Inc.; http://wso2.org >> >>> E-mail: hira...@wso2.com; Mobile: +94 77 633 3491 >> >>> Blog: http://techfeast-hiranya.blogspot.com >> >> >> >> >> >> >> >> -- >> >> Ruwan Linton >> >> Technical Lead & Product Manager; WSO2 ESB; http://wso2.org/esb >> >> WSO2 Inc.; http://wso2.org >> >> email: ru...@wso2.com; cell: +94 77 341 3097 >> >> blog: http://ruwansblog.blogspot.com >> > >> > >> > >> > -- >> > Asanka Abeysinghe >> > Architect - WSO2, Inc. >> > m: +94 77 7340064 p: +94 11 2688451/3 >> > e: asan...@wso2.com w: http://www.wso2.com >> > b: http://www.asankama.com >> > >> >> >> >> -- >> Regards, >> >> Rajith Attapattu >> Red Hat >> http://rajith.2rlabs.com/ >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org >> For additional commands, e-mail: dev-h...@synapse.apache.org >> > > > > -- > Asanka Abeysinghe > Architect - WSO2, Inc. > m: +94 77 7340064 p: +94 11 2688451/3 > e: asan...@wso2.com w: http://www.wso2.com > b: http://www.asankama.com > -- Regards, Rajith Attapattu Red Hat http://rajith.2rlabs.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org For additional commands, e-mail: dev-h...@synapse.apache.org
