M2 and protocol versions

[Robert Greig <ro...@gmail.com>]

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.

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.

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

RG

Re: M2 and protocol versions

[Robert Greig <ro...@gmail.com>]

On 04/09/07, Robert Godfrey <ro...@gmail.com> wrote:

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

I think we could have a default realm specifiable when creating the
ConnectionFactory. So if you use the default factory.createSession()
methods you get that realm, and we can have an "extended JMS" version
that takes a realm.

Adding the realm name to the URL would also be required as you say.

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

OK I think that is reasonable. It will require some more work so I
will raise a jira right now.

As soon as the vote is complete on M2 we should create an M2.1 branch.

Rajith, how are we looking for the M2 vote?

RG

Re: M2 and protocol versions

[Martin Ritchie <ri...@apache.org>]

On 04/09/07, Robert Godfrey <ro...@gmail.com> wrote:
> On 04/09/07, Robert Greig <ro...@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

Re: M2 and protocol versions

[Robert Godfrey <ro...@gmail.com>]

On 04/09/07, Robert Greig <ro...@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.

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.


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

-- Rob