AMQP v0-9
Locked
 
|
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 |
|
|
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 |
|
|
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, _______________________________________________ rabbitmq-discuss mailing list [hidden email] http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss |
|
|
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 |
|
|
On 23/08/07, Matthias Radestock <[hidden email]> wrote: Robert Godfrey wrote: 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 |
basic.consume filter arg [was: Re: AMQP v0-9]
|
|
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 |
|
|
In reply to this post by Rob Godfrey
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 +44 20 7617 7339 (UK) +44 77 9865 2911 (cell) +1 650 206 2517 (US) _______________________________________________ rabbitmq-discuss mailing list [hidden email] http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss |
Re: basic.consume filter arg [was: Re: AMQP v0-9]
|
|
In reply to this post by Matthias Radestock-2
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: _______________________________________________ rabbitmq-discuss mailing list [hidden email] http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss |
Re: basic.consume filter arg [was: Re: AMQP v0-9]
|
|
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 |
|
|
In reply to this post by Rob Godfrey
> 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 |
«
Return to RabbitMQ
|
1 view|%1 views
| Free forum by Nabble | Edit this page |