AMQP v0-9

[Martin Sustrik]

Matthias,

We've had OpenAMQ/RabbitMQ compatibility issue raised once more on
OpenAMQ mailing list:

"And one more important thing that we identified was  interoperability
of the brokers. say for example unlike the other middleware systems,
AMQP defines the protocol itself we should be able to send the messages
written in OpenAMQ client to RabitMQ server and vice versa. But with the
current implementations we cant do it. If you all can address that it
will be nice."

We've had discussion about this issue some time ago and at that point it
was unclear whether you are going to support 0-9 version of the
protocol. Was there any decision made meanwhile?

Martin

_______________________________________________
rabbitmq-discuss mailing list
[hidden email]
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss

[Matthias Radestock-2]

Martin,

Martin Sustrik wrote:
> We've had OpenAMQ/RabbitMQ compatibility issue raised once more on
> OpenAMQ mailing list:
> [...]
> We've had discussion about this issue some time ago and at that point it
> was unclear whether you are going to support 0-9 version of the
> protocol. Was there any decision made meanwhile?

I am trying to figure out how to best get RabbitMQ to interop with both
Qpid and OpenAMQ. As you may have seen from the other messages, we've
made some tweaks to get interop with Qpid M1 to work, and will release
those shortly.

The question is, if we move RabbitMQ to 0-9 in order to get interop with
OpenAMQ, how do we maintain interop with Qpid?

Are we going to have to have code that supports both 0-8 and 0-9 and
picks the right one during connection negotiation? That is certainly
possible, but it is quite a bit of work that I'd rather avoid.


Matthias.

_______________________________________________
rabbitmq-discuss mailing list
[hidden email]
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss

[Rob Godfrey]

My feeling is that any broker that supports 0-9 (non-WIP) should be able to also trivially support 0-8... So as long as our broker and client code follow the spec on how to negotiate version then we should be able to get interoperability.  In Qpid the Java simply didn't move forward to 0-9 (non WIP) as there wasn't a demand...  A lot of work was done on the C++ side for the 0-9 WIP proposals, but these have been superceded by the 0-10 proposals. 

-- Rob

On 23/08/07, Matthias Radestock <[hidden email]> wrote:

Martin,

Martin Sustrik wrote:
> We've had OpenAMQ/RabbitMQ compatibility issue raised once more on
> OpenAMQ mailing list:
> [...]
> We've had discussion about this issue some time ago and at that point it
> was unclear whether you are going to support 0-9 version of the
> protocol. Was there any decision made meanwhile?

I am trying to figure out how to best get RabbitMQ to interop with both
Qpid and OpenAMQ. As you may have seen from the other messages, we've
made some tweaks to get interop with Qpid M1 to work, and will release
those shortly.

The question is, if we move RabbitMQ to 0-9 in order to get interop with
OpenAMQ, how do we maintain interop with Qpid?

Are we going to have to have code that supports both 0-8 and 0-9 and
picks the right one during connection negotiation? That is certainly
possible, but it is quite a bit of work that I'd rather avoid.


Matthias.

_______________________________________________
rabbitmq-discuss mailing list
[hidden email]
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss

_______________________________________________
rabbitmq-discuss mailing list
[hidden email]
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss

[Matthias Radestock-2]

Robert Godfrey wrote:
> My feeling is that any broker that supports 0-9 (non-WIP) should be able
> to also trivially support 0-8.

It's not that easy, unfortunately. 0-9 makes some changes to existing
methods. For example, channel.open-ok gets an additional channel-id
field, and basic.consume gets an additional filter field. If, like us,
you are auto-generating the codec from the spec then this poses a problem.

Matthias.

_______________________________________________
rabbitmq-discuss mailing list
[hidden email]
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss

[Rob Godfrey]

On 23/08/07, Matthias Radestock <[hidden email]> wrote:

Robert Godfrey wrote:
> My feeling is that any broker that supports 0-9 (non-WIP) should be able
> to also trivially support 0-8.

It's not that easy, unfortunately. 0-9 makes some changes to existing
methods. For example, channel.open-ok gets an additional channel-id
field, and basic.consume gets an additional filter field. If, like us,
you are auto-generating the codec from the spec then this poses a problem.

Qpid auto generates code from the spec, but with changes this small I would think we could work in a few bits of non-generated code to support both versions.  Given the degree of change in 0-10 I'm not wanting to expend much effort on 0-9 - but I think that having 0-9 compatability at the broker really shouldn't be a big deal (it may not be able to be done with particular beauty though).  [For instance I think Qpid actually already has the basic.consume filter argument].

Given Martin's claim that it took them 1 day to implement the changes... i would think that it should be possible for Qpid (and Rabbit if you like) to have versions that work with both protocol revisions.  However the real focus will be on getting 0-10 implemented.


-- Rob

Matthias.

_______________________________________________
rabbitmq-discuss mailing list
[hidden email]
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss

[Matthias Radestock-2]

Robert Godfrey wrote:
>[For instance I think Qpid actually
> already has the basic.consume filter argument].

When you say "already", do you mean in M1? I have been working with the
Qpid M1 source distribution and the auto-generated codec there certainly
does not have the additional arg. Perhaps the binary distributions do?

Can you find out? I am asking because I want to make sure I am not
missing something in my interop testing.

I know that the 0-8 spec in the current Qpid svn repo is different from
the official spec, and the addtional arg to basic.consume is part of that.

What flavour of the 0-8 spec will the M2 release be based on?


Matthias.

_______________________________________________
rabbitmq-discuss mailing list
[hidden email]
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss

[Alexis Richardson-2]

Rob

That would be great.  Then we have a baseline to work from when
dealing with implementation upgrades (eg your M2 release), and spec
changes (eg 0-10).

alexis


On 8/23/07, Robert Godfrey <[hidden email]> wrote:

>
> On 23/08/07, Matthias Radestock <[hidden email]> wrote:
> > Robert Godfrey wrote:
> > > My feeling is that any broker that supports 0-9 (non-WIP) should be able
> > > to also trivially support 0-8.
> >
> > It's not that easy, unfortunately. 0-9 makes some changes to existing
> > methods. For example, channel.open-ok gets an additional channel-id
> > field, and basic.consume gets an additional filter field. If, like us,
> > you are auto-generating the codec from the spec then this poses a problem.
>
>
> Qpid auto generates code from the spec, but with changes this small I would
> think we could work in a few bits of non-generated code to support both
> versions.  Given the degree of change in 0-10 I'm not wanting to expend much
> effort on 0-9 - but I think that having 0-9 compatability at the broker
> really shouldn't be a big deal (it may not be able to be done with
> particular beauty though).  [For instance I think Qpid actually already has
> the basic.consume filter argument].
>
> Given Martin's claim that it took them 1 day to implement the changes... i
> would think that it should be possible for Qpid (and Rabbit if you like) to
> have versions that work with both protocol revisions.  However the real
> focus will be on getting 0-10 implemented.
>
>
> -- Rob
>
> > Matthias.
> >
>
>
> _______________________________________________
> rabbitmq-discuss mailing list
> [hidden email]
> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>
>

--
Alexis Richardson
[phone] (UK)
[phone] (cell)
[phone] (US)

_______________________________________________
rabbitmq-discuss mailing list
[hidden email]
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss

[Rob Godfrey]

Hi Matthias,

M1 was before my time :-) 

M2 will be using the 0-8 spec file that is within the specs directory in the qpid apache svn repository.  It has an "arguments" argument (essentially the filters argument from 0-9 with the 0-10 name, not that names are important at the wire level).  There are some other additions to the correct 0-8 specbut these are essentially additions, and as long as the strict amqp flag is passed to the qpid client then the client won't use them ...

-- Rob

On 23/08/07, Matthias Radestock <[hidden email]> wrote:

Robert Godfrey wrote:
>[For instance I think Qpid actually
> already has the basic.consume filter argument].

When you say "already", do you mean in M1? I have been working with the
Qpid M1 source distribution and the auto-generated codec there certainly
does not have the additional arg. Perhaps the binary distributions do?

Can you find out? I am asking because I want to make sure I am not
missing something in my interop testing.

I know that the 0-8 spec in the current Qpid svn repo is different from
the official spec, and the addtional arg to basic.consume is part of that.

What flavour of the 0-8 spec will the M2 release be based on?


Matthias.

_______________________________________________
rabbitmq-discuss mailing list
[hidden email]
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss

[Matthias Radestock-2]

Robert Godfrey wrote:
> M2 will be using the 0-8 spec file that is within the specs directory in
> the qpid apache svn repository.

I have to say that calling that file "amq.0-8.xml" in your source tree,
when it is different from the official spec is rather confusing. It took
me a while to notice that difference.

> It has an "arguments" argument
> (essentially the filters argument from 0-9 with the 0-10 name, not that
> names are important at the wire level).  There are some other additions
> to the correct 0-8 specbut these are essentially additions, and as long
> as the strict amqp flag is passed to the qpid client then the client
> won't use them ...

Please make sure that flag is documented very prominently. Otherwise we
are bound to get complaints from people who try to get interop to work.

Will the flag also work for the python test suite?

What about the server side of things, i.e. ensuring that a client which
conforms to the official 0-8 spec can talk to a Qpid server? Looking at
the differences between the official spec and the one in the qpid source
tree, there are two places where interop will get broken if the server
is not constrained to official 0-8 behaviour:

- it must accept basic.consume messages without the filter arg

- it must not send a basic.recover-ok response

How are you planning to handle this?


Matthias.

_______________________________________________
rabbitmq-discuss mailing list
[hidden email]
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss

[Martin Sustrik]

> Given Martin's claim that it took them 1 day to implement the changes...
> i would think that it should be possible for Qpid (and Rabbit if you
> like) to have versions that work with both protocol revisions.  However
> the real focus will be on getting 0-10 implemented.

It's really not much work (the most difficult task being Queue.Unbind
which is important for clients anyway) and that way we'll show to
outside world that AMQP is really about interoperability - that the
claim in not a total bogus.

It would also allow Qpid and RabbitMQ teams to use Wireshark to dissect
AMQP packets, which is quite useful IMO.

Martin

_______________________________________________
rabbitmq-discuss mailing list
[hidden email]
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss