Hi Uli, On 20 December 2013 20:00, uromahn <[email protected]> wrote:
> I have a general question to this community, especially to the active > project > committers: > > I was wondering what the status of the amqp-1-0-* libraries is and if this > is even still actively maintained? > > I was planning to use the AMQP-1-0- JMS client library in my project here > and started testing it out with a very simple proof-of-concept. > The amqp-1-0 libraries grew out of work I did in proving out the original AMQP specification and then subsequently demonstrating that you could implement JMS on top of it. Since there was a lot of interest in people using JMS over AMQP I added the libraries to the Qpid project, but when I originally wrote the code it wasn't really with the expectation of supporting it long term. As you mention there is a JMS 2.0 client which we are building on top of the Proton API which is the client that we will ultimately be wanting to migrate to for JMS over AMQP. > However, even the very first steps were very discouraging since I > encountered some serious bugs and very strange behavior (see Jira tickets > QPID-5348 and QPID-5349 as two examples). Obviously the two cases above should have timeouts in the waits and should then fail. The JMS client has been tested mostly against the Qpid Java broker, ActiveMQ, Microsoft Azure Service Bus and SwiftMQ... I've not personally done much testing against the C++ broker (since it doesn't build on my primary development environment) and obviously doing that is showing up issues where the C++ broker is not behaving "as expected" and the JMS client is then not coping very well. In addition, the client does not > yet fully implement the complete JMS 1.1 spec (e.g. no XA support), and > there seems to be some subtle deviations from the spec in some areas. > Distributed transactions are not yet officially supported by AMQP 1.0 (though really it's not a big stretch for it to be added, the AMQP group just haven't got to it yet). If you have examples of deviation from the spec please let us know - I know the client has been tested with the JMS TCK against at least two different brokers, but that doesn't catch all of the JMS spec. > Also, when looking at the current code, I don't really get a good "warm and > fuzzy" feeling since the code quality seems very questionable in many > places > (sorry for being so brutally honest here, but I have very high personal > standards when it comes to Java). > > I also noticed that there is a new project to build a JMS 2.0 client based > on Proton, however, this does not seem to have a lot of traction and > activity and it is far from being close to production readiness. > > So, here is my final question: > should I just abandon the idea to use JMS together with AMQP 1-0 and switch > to ProtonJ (which seems much better :) ) or is there hope that we can get > the existing JMS-AMQP-1-0 client libraries to some level of quality? I am > willing to chip in some of my time, but I don't want to be the "lonely > warrior" here. > > There are actually a fair number of people using the existing JMS client based on the amqp-1-0-* libraries (more than I ever expected :) ) so you certainly wouldn't be the only one looking at it. As above, our plans are to move to a client based on Proton and a definitive AMQP to JMS mapping, but that client is really only beginning to get serious development efforts thrown at it. Whether to use the existing JMS client really depends on what your needs are... (and which Proton API you are looking at - the engine, or the messenger API... if you're looking at using any kind of transactions then I don't think messenger supports transactions at all currently). Hope this helps, Rob -Uli > > > > -- > View this message in context: > http://qpid.2158936.n2.nabble.com/INQUIRY-Status-of-qpid-java-amqp-1-0-client-jms-library-tp7602075.html > Sent from the Apache Qpid users mailing list archive at Nabble.com. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
