qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Ritchie" <ritch...@apache.org>
Subject Re: M2 and protocol versions
Date Tue, 04 Sep 2007 11:06:36 GMT
On 04/09/07, Robert Godfrey <rob.j.godfrey@gmail.com> wrote:
> On 04/09/07, Robert Greig <robert.j.greig@gmail.com> 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

Mime
View raw message