On Fri, Nov 27, 2009 at 12:23 AM, Ruwan Linton <ruwan.lin...@gmail.com> wrote: > +1, can some one do a PoC on RabitMQ with the JMS transport?
Qpid and RabbitMQ did some work to figure out how well the clients and brokers worked with each other. I have contacted a RabbitMQ guy who may have a document that describes the config on both sides and a list of issues. An example of how you could use the Qpid JMS client + Synapse/Axis2 JMS transport with Qpid/RabbitMQ brokers is definitely a good idea. I think Suran already did the Qpid broker part and both him and I have written a blog entry with the details, So a similar exercise for RabbitMQ broker is a good addition. If somebody could provide a list of use cases around Synapse + AMQP I could write up how we can configure Synapse and Qpid to achieve those. > and if it is > successful then submit that as a sample on to synapse, if we fail to do > that, what ever the theory is, we will have to go for a native AMQP or some > transport which can work with AMQP providers like RabitMQ. I have outlined the challenges/cost/benefit for both approaches. What exactly to do is a decision that you folks need to make as a project. Sure I am part of the PMC, but the truth is I haven't been active at all in the last 2 years or so with the exception of an occasional email. So I am not going to be part of the decision making process, plus I am bias too :) Work out and see how well the JMS transport + Qpid JMS client could satisfy the Synapse use cases, including the ability to work with different AMQP providers. Look at what's happening in the AMQP landscape in the future. Paul is an excellent source here as he attends AMQP PMC meetings. Then see what makes sense for the project going forward. > Lahiru, whould you like to do this? Or may be Rajith :-) > > Thanks, > Ruwan > > On Fri, Nov 27, 2009 at 9:41 AM, Hiranya Jayathilaka <hiranya...@gmail.com> > wrote: >> >> >> On Thu, Nov 26, 2009 at 8:42 PM, Rajith Attapattu <rajit...@gmail.com> >> wrote: >>> >>> On Wed, Nov 25, 2009 at 11:22 PM, 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. >>> >>> Good question and one for the FAQ. >>> AMQP servers does not need to be aware of JMS or support JNDI. >>> The Qpid client (or for that matter any JMS client built on top of >>> AMQP) will map JMS semantics on to AMQP, and the protocol takes care >>> of the rest. >>> The AMQP WG does understand the prominence of JMS very well, hence >>> have taken that into account when designing the protocol. >>> >>> You could use Qpid JNDI to represent pre created AMQP queues (using a >>> management tool), or you could dynamically create these queues based >>> on the destination configuration. >>> The new address syntax for all language clients that Qpid is currently >>> working on has a lot more flexibility than the older format. >>> For example It could do things, like specify declare arguments (to >>> make use of provide specific features like >>> max-queue-size,max-queue-count, reject-policy ..etc) >>> Another example is setting destination specific flow control, or >>> reliability expectations. >>> Another important point to note is that, this configuration is done >>> with AMQP 1.0 in mind. So you could just upgrade to an AMQP 1.0 server >>> __without any code changes__ >>> >>> Another benefit of the JMS transport is that you could use it to talk >>> to RabbitMQ or Qpid brokers. >> >> Can we use the JMS transport to talk with brokers like RabbitMQ which are >> not written in Java? Do you mean to say that we can already use the Axis2 >> JMS transport to connect with JMS unaware AMQP brokers? If that can be done >> then I'm ready to give up the idea of writing a native AMQP transport. >> However we need to properly document such tasks by providing sufficient >> samples. >> >> Thanks, >> Hiranya >> >>> >>> If we use a native AMQP transport it will likely be very close to a >>> particular protocol version and the sensible option is to use 0-10 or >>> go straight to 1.0 >>> It should be noted there are significant semantic differences between >>> 0-8/0-9, 0-10 and 1.0 versions of the protocol. >>> So it will not work with RabbitMQ. If you use 1.0 currently no >>> production versions exist as the protocol is yet to be ratified. >>> If that is taken into account you will end up writing a higher level >>> client that is protocol agnostic, which would quite bit of work for no >>> real benefit. >>> So why not use the JMS transport? >>> >>> The RabbitMQ sever is at 0-8 (0-9 too ??) version of the protocol, >>> while the Qpid java broker supports 0-8,0-9,0-10 and the c++ broker >>> only the 0-10 version. >>> However the Qpid JMS client supports all (0-8,0-9 and 0-10) versions >>> of the protocol. >>> So you should be able to use the JMS transport with RabbitMQ or Qpid. >>> (The Qpid client and RabbitMQ does have a few quirks, and that is more >>> due to issues with the 0-8 protocol and to the fact that some features >>> are not supported by one vendor) >>> >>> So in summary I still don't see any tangible benefit of having a >>> native AMQP transport, unless we have some very compelling use cases. >>> Infact I think for a project like Synapse using AMQP via JMS seems >>> like a safe bet. >>> But if someone is willing to experiment, I wouldn't stand in the way >>> either :) >>> >>> > 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 >>> > >>> >>> >>> >>> -- >>> 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 > -- 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
