Re: [Fwd: Re: basic.consume filter arg [was: Re: AMQP v0-9]]

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

On 28/08/07, Matthias Radestock <ma...@lshift.net> wrote:
> Martin,
>
> I understand that Rob is on holiday. In his absence, could you perhaps
> answer the questions in the attached email regarding interop in Qpid M2?
> Thanks.
>
>
> Matthias.
> PS: If you can, please reply to the original email on rabbitmq-discuss,
> since at the moment it is sitting there unanswered.
>
> 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.

Point taken we should probably have highlighted the issue. Would have
been great if our generator could have taken the standard spec and
merged an errata file so we had a single file that showed the
differences.

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

I haven't done any development work on the Python.
I only implemented the flag for the Java Client suite so the python
may need to be rebuilt against a true 0_8 spec file.

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

Indeed this will be an issue for interop. Currently the broker always
sends a recover-ok and from what I can see taking a brief look the
Consume method always reads the arguments field from the consume body.
What I guess that the Qpid C++ and .Net clients work correctly with
the Java broker as they all use the same spec file.

Unfortunately we are to late to make changes to the M2 release which
should be just as soon as we can get it voted through... though there
is an argument that this is a fairly major interop issue and a similar
STRICT_AMQP flag should be added to the Java M2 Broker to facility
AMQP interop. The changes wouldn't take much work so I've copied the
Qpid-Dev list in to see if they are happy to make this change for M2.

Off the top of my head there isn't any other items other than bugs
that might prevent interop. I'm not 100% convinced about our
Basic.Reject handling for instance.

-- 
Martin Ritchie

Re: [Fwd: Re: basic.consume filter arg [was: Re: AMQP v0-9]]

[Carl Trieloff <cc...@redhat.com>]

Matthias Radestock wrote:
>
> Matthias
> PS: I have copied the rabbitmq-discuss list, where this thread 
> originated.

As the the thread covers two lists, how do I subscribe to that discuss list?
Carl.

Re: [rabbitmq-discuss] [Fwd: Re: basic.consume filter arg [was: Re: AMQP v0-9]]

[Rajith Attapattu <ra...@gmail.com>]

off the top of my head I know the following are scoped for 0-11.

Support for JMS destinations.
Message Selectors - all though there is implicit support for this in 0-10 by
doing a consume in no-acquire mode and using client side selectors.
Other than that I believe we have nailed the other issues - but a quick
check will not hurt.

The official guide for AMQP-JMS Mapping is scoped for 0-11, and I expect by
then we have full protocol level support for JMS.

Rajith

On 8/28/07, Rafael Schloming <ra...@redhat.com> wrote:
>
> Robert Greig wrote:
> > On 28/08/07, Matthias Radestock <ma...@lshift.net> wrote:
> >
> >> Another option is to stick to the published 0-8 spec. Does Qpid
> >> definitely require the modifications you have made to the spec? If yes,
> >> is there perhaps a way to achieve the same functionality with
> extensions
> >> that do not break 0-8 interop?
> >
> > At least some of the changes were introduced for JMS compliance, i.e.
> > when working on passing the TCK Rob and I realised that we simply
> > could not get JMS compatibility without making some changes (e.g.
> > adding methods).
> >
> > It would be useful to gather together the changes then I and others
> > can try to recollect the precise reasoning behind them. Perhaps we
> > could modify the approach if a more compatible one was possible or
> > maybe RabbitMQ could adopt some of them in the interests of achieving
> > JMS compatibility (or have you managed to do this with unmodified
> > 0-8?).
> >
> > We did at least discuss most if not all of these changes on the AMQP
> > list but at the time getting any changes accepted particularly when
> > people mentioned the acronym "JMS" was very time consuming and
> > draining.
>
> FWIW, I believe most if not all of these changes are in 0-10 in one form
> or another. Of course gathering together the changes and verifying that
> wouldn't be a bad idea.
>
> --Rafael
>
>

Re: [rabbitmq-discuss] [Fwd: Re: basic.consume filter arg [was: Re: AMQP v0-9]]

[Rafael Schloming <ra...@redhat.com>]

Robert Greig wrote:
> On 28/08/07, Matthias Radestock <ma...@lshift.net> wrote:
> 
>> Another option is to stick to the published 0-8 spec. Does Qpid
>> definitely require the modifications you have made to the spec? If yes,
>> is there perhaps a way to achieve the same functionality with extensions
>> that do not break 0-8 interop?
> 
> At least some of the changes were introduced for JMS compliance, i.e.
> when working on passing the TCK Rob and I realised that we simply
> could not get JMS compatibility without making some changes (e.g.
> adding methods).
> 
> It would be useful to gather together the changes then I and others
> can try to recollect the precise reasoning behind them. Perhaps we
> could modify the approach if a more compatible one was possible or
> maybe RabbitMQ could adopt some of them in the interests of achieving
> JMS compatibility (or have you managed to do this with unmodified
> 0-8?).
> 
> We did at least discuss most if not all of these changes on the AMQP
> list but at the time getting any changes accepted particularly when
> people mentioned the acronym "JMS" was very time consuming and
> draining.

FWIW, I believe most if not all of these changes are in 0-10 in one form 
or another. Of course gathering together the changes and verifying that 
wouldn't be a bad idea.

--Rafael

Re: [rabbitmq-discuss] [Fwd: Re: basic.consume filter arg [was: Re: AMQP v0-9]]

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

On 28/08/07, Matthias Radestock <ma...@lshift.net> wrote:

> Another option is to stick to the published 0-8 spec. Does Qpid
> definitely require the modifications you have made to the spec? If yes,
> is there perhaps a way to achieve the same functionality with extensions
> that do not break 0-8 interop?

At least some of the changes were introduced for JMS compliance, i.e.
when working on passing the TCK Rob and I realised that we simply
could not get JMS compatibility without making some changes (e.g.
adding methods).

It would be useful to gather together the changes then I and others
can try to recollect the precise reasoning behind them. Perhaps we
could modify the approach if a more compatible one was possible or
maybe RabbitMQ could adopt some of them in the interests of achieving
JMS compatibility (or have you managed to do this with unmodified
0-8?).

We did at least discuss most if not all of these changes on the AMQP
list but at the time getting any changes accepted particularly when
people mentioned the acronym "JMS" was very time consuming and
draining.

RG

Re: [rabbitmq-discuss] [Fwd: Re: basic.consume filter arg [was: Re: AMQP v0-9]]

[Matthias Radestock <ma...@lshift.net>]

Matthias Radestock wrote:

> The cleanest solution to all the above would be to use a version number 
> other than 0-8 for the Qpid-modified 0-8 protocol, and for the broker 
> and clients to support both that and the official 0-8, and negotiate an 
> appropriate fit. That is problematic though because there isn't room in 
> the version numbering scheme for, say, a 0-8-1.
> 
> An alternative might be for the Qpid clients and servers to detect each 
> other via the product info passed as part of connection negotiation. 
> Then, when a Qpid client meets a Qpid broker they could automatically 
> speak Qpid-modified 0-8 whereas when paired up with anything else they 
> would revert to standard 0-8.

Another option is to stick to the published 0-8 spec. Does Qpid 
definitely require the modifications you have made to the spec? If yes, 
is there perhaps a way to achieve the same functionality with extensions 
that do not break 0-8 interop?


Matthias.

Re: [Fwd: Re: basic.consume filter arg [was: Re: AMQP v0-9]]

[Matthias Radestock <ma...@lshift.net>]

Martin,

Martin Ritchie wrote:
> On 28/08/07, Matthias Radestock <ma...@lshift.net> wrote:
>> Will the flag also work for the python test suite?
> 
> I haven't done any development work on the Python.
> I only implemented the flag for the Java Client suite so the python
> may need to be rebuilt against a true 0_8 spec file.

That is fine, in a way, and is what we are doing now.

The problem though is, again, the confusion arising from the fact that 
the test suite pulls in the Qpid-modified 0-8 spec - both by default and 
when specifying "0-8" as the specfile. We have had complaints from 
people who ran the test suite that way against RabbitMQ and were 
surprised to see errors.

>> 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?
>>
> Indeed this will be an issue for interop. Currently the broker always
> sends a recover-ok and from what I can see taking a brief look the
> Consume method always reads the arguments field from the consume body.
> What I guess that the Qpid C++ and .Net clients work correctly with
> the Java broker as they all use the same spec file.
> 
> Unfortunately we are to late to make changes to the M2 release which
> should be just as soon as we can get it voted through... though there
> is an argument that this is a fairly major interop issue and a similar
> STRICT_AMQP flag should be added to the Java M2 Broker to facility
> AMQP interop. The changes wouldn't take much work so I've copied the
> Qpid-Dev list in to see if they are happy to make this change for M2.

A flag would be good but is still far from ideal, for two reasons:

1) as I mentioned above, it causes all sorts of headaches for other 
implementations and users when an AMQP broker advertises support for 0-8 
during protocol negotiation but the departs from the spec in crucial 
areas that break interop at fairly low levels of the protocol.

2) the protocol flavour (i.e. official 0-8 vs Qpid-modified 0-8) should 
be settable on a per-connection basis. Otherwise, for example, you will 
not be able to connect to a Qpid broker with a non-Qpid client unless a) 
the broker was started with that flag, and b) all Qpid clients are 
started with that flag.

The cleanest solution to all the above would be to use a version number 
other than 0-8 for the Qpid-modified 0-8 protocol, and for the broker 
and clients to support both that and the official 0-8, and negotiate an 
appropriate fit. That is problematic though because there isn't room in 
the version numbering scheme for, say, a 0-8-1.

An alternative might be for the Qpid clients and servers to detect each 
other via the product info passed as part of connection negotiation. 
Then, when a Qpid client meets a Qpid broker they could automatically 
speak Qpid-modified 0-8 whereas when paired up with anything else they 
would revert to standard 0-8.


Regards,

Matthias
PS: I have copied the rabbitmq-discuss list, where this thread originated.

Re: [Fwd: Re: basic.consume filter arg [was: Re: AMQP v0-9]]

[Carl Trieloff <cc...@redhat.com>]

>
> If we want to expand the scope of our interop testing to other AMQP
> implementations we should take that on as a work item and do some
> proper structured testing, with a view to release an M2.1 

+1, let's get the M2 RC out. I am sure we will do a M2.1 once M3 goes 
out for a compat
issue here and there/ or some bug fixes.

Carl.

Re: [Fwd: Re: basic.consume filter arg [was: Re: AMQP v0-9]]

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

On 28/08/07, Martin Ritchie <ri...@apache.org> wrote:

> Unfortunately we are to late to make changes to the M2 release which
> should be just as soon as we can get it voted through... though there
> is an argument that this is a fairly major interop issue and a similar
> STRICT_AMQP flag should be added to the Java M2 Broker to facility
> AMQP interop. The changes wouldn't take much work so I've copied the
> Qpid-Dev list in to see if they are happy to make this change for M2.

My view is that M2 has been on the go for a while now and we really
need to get the vote done and dusted on it ideally without any further
changes.

If we want to expand the scope of our interop testing to other AMQP
implementations we should take that on as a work item and do some
proper structured testing, with a view to release an M2.1 or M3
release which has some guarantee of interop. There are bound to be
other things that get uncovered and it is better not to delay M2
further.

RG