On 04/09/07, Robert Godfrey <[EMAIL PROTECTED]> wrote: > On 04/09/07, Robert Greig <[EMAIL PROTECTED]> wrote: > > > > Hi all, > > > > Yesterday I tried some interoperability testing with Qpid Java and C++ > > and OpenAMQ 1.2c3. I used the topic test client (both C++ and Java > > versions). > > > > Following on from earlier discussions, we have what I think is a > > serious issue in that M2 advertises 0-8 protocol version in the > > ProtocolInitiation, but isn't really 0-8. It is closer to 0-9 but as > > it turns out isn't 0-9 either. > > > > Completely agree - we should really not be advertising that we are 0-8 (or > rather 8-0) in Protocol Initialisation... > > The biggest issue for M2 achieving basic interop with other 0-8 > > products is the basic.consume extra argument. There is also the issue > > of Access - Rabbit looks like it needs something around that although > > there are some docs that enable suppression of it for their java > > client. > > > > Yep - we should add some basic Access support (i've done this before - it > seems to have got removed somewhere along the line). The biggest issue is > how to do this in a way that is "JMS" friendly - the only way I can see is > to add a realm to the connection URL somehow, and let the library ask for > that realm (and get the ticket) before anything else.
The URL is currently extensible with any key='value' pairing. We could very easily query the connection URL for a realm and pervorm Access commands if present. > For 0-9, which is what OpenAMQ 1.2c3 supports I had to make a couple of > > changes: > > > > 1) channel.open-ok now returns an id > > 2) connection.close is now index 50 rather than 60 due to some > > renumbering (redirect used to be 50 but is now 42 (?!?)). > > > > There was also a bug in OpenAMQ where it did not respond to the > > basic.qos method which I had to comment out in our clients. > > > > The above test is just about as simple as you can get and today none > > of the products, with any version, can interoperate. I think we should > > address this and it is not a huge amount of effort to do so. > > > > Here is what I am tentatively proposing: > > > > 1) Aim to do an M2.1 release focussing on interop as soon as possible > > 2) All Qpid products will support 0-9 protocol and only extensions > > (i.e. non-conflicting) changes are allowed to that protocol. > > 3) For the interop testing have a small (achievable) but simple pair of > > tests: > > a) topic test (I have resurrected the java version and we have a C++ > > client for this already) > > b) transactional point to point > > > > If others agree I think we should start planning the hopefully small > > amount of work required to make this happen. > > > > Completely agree. I would go one stage further and say we ought to try to > maintain compatability with M2 as well - i.e. have a modicum of > multi-version support. Certainly for organisations with large installed > bases of Qpid use, this would make the upgrade path easier. +1 > I think having interop will help us because it will give users > > confidence that the AMQP protocol is useful and beneficial. It will > > also enable easier comparisons of non-functionals to be done across > > products, and I think we should have enough confidence in Qpid to be > > sure that it will come out well in such tests. My indications are that > > we look good on the performance front (see separate email). > > > > RG > > > > +1 +1 > -- Rob > -- Martin Ritchie
