qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Greig" <robert.j.gr...@gmail.com>
Subject M2 and protocol versions
Date Tue, 04 Sep 2007 07:51:34 GMT
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

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.

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

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.

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).


View raw message