You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Gordon Sim <gs...@redhat.com> on 2007/01/17 13:25:39 UTC
[java] AMQP compliance and the Java client
Achieving JMS compliance has necessitated some non-standard protocol
extensions/alterations. To use all JMS features, only a broker that
supports these extensions/alterations can be used (currently only the
java broker[*]). Further, the java client can not at present be used in
*any* capacity with a broker that does not support these extensions.
The key issue is the extended value types for field tables[**] and in
particular uses of non-standard types that occur automatically for any
application using the java client. Those uses are listed below.
Is this an issue for anyone but me? I've suggested some ways of trying
to avoid these uses and would appreciate your thoughts.
(1) The client properties sent in connection.start-ok use non-standard
types (ASCII_STRING).
In AMQType, LONG_STRING, WIDE_STRING and ASCII_STRING are currently all
identical in implementation, differing only in the typecode used, and
this seems to have been sufficient for JMS compliance.
As they seem to be equivalent, are there any objections to using only
LONG_STRING, which is an AMQP standard type? There seems to be little
point in deviating from the standard where we currently gain no benefit
from doing so.
That would solve the immediate problem and also enable String message
properties to be used.
(2) BasicMessagePublisher sets a property of a non-standard type
(BINARY) on all messages sent.
This is the CustomJMSXProperty.JMSX_QPID_JMSDESTINATIONURL property. I
am not clear in what this is used for. It is currently read in
BasicMessageConsumer only where CLIENT_ACKNOWLEDGE mode has been set.
Can anyone shed a bit more light on what this property is used for, as
that may open up other options for getting around this issue?
As an aside, the java implementation for the 'BINARY' type seems to use
a single byte for the size, whereas the proposal on the wiki specifies 4
bytes for the size. 256 bytes is a bit limiting for a binary type.
The reason for sending it as binary is (as I understand it) efficiency.
The value is composed of different parts, and parsing these on the
receiver is faster and simpler using raw bytes.
Of course in terms of the wire transfer this would not rule out the use
of LONG_STRING, but the FieldTable class converts any values marked as
LONG_STRING into java String objects and reconverting that to a byte
array would have incurred some unnecessary overhead.
We could alter this so that FieldTable holds LONG_STRING values as byte
arrays, and the conversion to and from strings is done separately in the
setters and getters that use the String type. We could then allow
alternate setters and getters that accessed the raw bytes (these would
be separate also from the getBytes()/setBytes() which have to use a
separate type identifier for JMS compliance). Any comments on that approach?
[*] I will update the c++ broker at some point to also recognise the
extended types which will at least allow interoperability within the
qpid project.
[**] The basic.consume method has a non-standard field, but as this has
been added in 0-9, once we move to that version this issue will cease to
concern us. One side effect worth pointing out though is that the M1
release will not be interoperable with the current trunk.
Re: [java] AMQP compliance and the Java client
Posted by Robert Godfrey <ro...@gmail.com>.
That appears to be a bug :-)
I have *no* idea why it is in that if block...
- Rob
Re: [java] AMQP compliance and the Java client
Posted by Gordon Sim <gs...@redhat.com>.
Robert Godfrey wrote:
> To shed some light on the use of the custom property...
>
> It is used to support the notion of getJMSDestination() on a JMSMessage
>
> That is JMS requires us to know the original destination (in JMS terms)
> that
> the message was sent to, We originally did this by sending the BindingURL
> as a long string, however this proved to be very inefficient.
>
> The current solution of sending a byte-encoded representation of the
> Destination is still not correct. In general we need to think through the
> whole notion of what a destination is in QPID / AMQP.
>
> We probably need a change at the protocol level to ensure that the original
> intended destination is included in the header, but for this we need to be
> clear on what a destination is. It cannot simply be exchange and routing
> key, as we need to consider the case of topologies of brokers wired
> together. Thus we need a globally unique destination name to provide
> correct equality semantics.
>
> - Rob
Thanks for the update Rob. Was I wrong in saying that property is only
ever read when the session is in client acknowledge mode? Or is that
just a bug?
Re: [java] AMQP compliance and the Java client
Posted by Gordon Sim <gs...@redhat.com>.
Robert Godfrey wrote:
> To shed some light on the use of the custom property...
>
> It is used to support the notion of getJMSDestination() on a JMSMessage
>
> That is JMS requires us to know the original destination (in JMS terms)
> that
> the message was sent to, We originally did this by sending the BindingURL
> as a long string, however this proved to be very inefficient.
>
> The current solution of sending a byte-encoded representation of the
> Destination is still not correct. In general we need to think through the
> whole notion of what a destination is in QPID / AMQP.
>
> We probably need a change at the protocol level to ensure that the original
> intended destination is included in the header, but for this we need to be
> clear on what a destination is. It cannot simply be exchange and routing
> key, as we need to consider the case of topologies of brokers wired
> together. Thus we need a globally unique destination name to provide
> correct equality semantics.
The new message.transfer method (0-9, WIP) has both the exchange and
routing key in it which should at least allow the custom property to be
removed.
I appreciate that the original host should be recorded as well once it
is possible to construct topologies of brokers wired together. Perhaps
we can use a custom (long string) property for that if we need it before
the spec is updated.
In AMQP I think a destination is simply an exchange (on a particular
broker, perhaps in a particular virtual host). However an AMQP
destination and a JMS destination are different things. For JMS purposes
the destination is an AMQDestination (or subclass) instance populated
with the 'correct' settings, which need to be obtainable in some way
from the message.
How we define 'correct' is, as Rajith's mail points out, still a little
open: it could either be the details with which the message was
published or details that would uniquely address the queue from which
the message has been consumed. From a JMS compliance perspective, I'm
not sure that this difference would even be visible. I would lean
towards what Rajith described as the 'publisher's view'.
Re: [java] AMQP compliance and the Java client
Posted by Rajith Attapattu <ra...@gmail.com>.
Very Good Question here.
I had quite an argument with Robert Greig about the *Destination* and how
it's relevant within the context of AMQP.
As Robert says and as I previously mentioned to Robert Greig "routing key"
is not really a destination. But I agree that it is the most accurate view
of the destination.
I see two possible angles.
One is the virtual destination identified by the routing key which could
match to several physical queues.
Based on the matching criteria the message could end up in several queues.
The routing key is the Producers view of the "Destination".
The other option for Destination is the physical queue that the message was
consumed from.
The physical queue is the Consumers view of the "Destination".
Robert Greig argued that from a clients perspective the latter is useless as
the client already knows which queue it consumed this message from.
His argument was, that the virtual destination is more usefull to a client
for error handling and other logic. I see that as a very valid use case.
During our disscussion we did a search and found out that in messaging terms
the expected behaviour of the Destination field is to represent the
Producers view of the "Destination".
Therefore I think the routing key is so far the most deserving candidate for
the Destination in terms of AMQP.
However I stand to be corrected on this issue and I would like to see some
comments around this.
Regards,
Rajith
On 1/17/07, Robert Godfrey <ro...@gmail.com> wrote:
>
> To shed some light on the use of the custom property...
>
> It is used to support the notion of getJMSDestination() on a JMSMessage
>
> That is JMS requires us to know the original destination (in JMS terms)
> that
> the message was sent to, We originally did this by sending the BindingURL
> as a long string, however this proved to be very inefficient.
>
> The current solution of sending a byte-encoded representation of the
> Destination is still not correct. In general we need to think through the
> whole notion of what a destination is in QPID / AMQP.
>
> We probably need a change at the protocol level to ensure that the
> original
> intended destination is included in the header, but for this we need to be
> clear on what a destination is. It cannot simply be exchange and routing
> key, as we need to consider the case of topologies of brokers wired
> together. Thus we need a globally unique destination name to provide
> correct equality semantics.
>
> - Rob
>
>
> On 17/01/07, Gordon Sim <gs...@redhat.com> wrote:
> >
> > Achieving JMS compliance has necessitated some non-standard protocol
> > extensions/alterations. To use all JMS features, only a broker that
> > supports these extensions/alterations can be used (currently only the
> > java broker[*]). Further, the java client can not at present be used in
> > *any* capacity with a broker that does not support these extensions.
> >
> > The key issue is the extended value types for field tables[**] and in
> > particular uses of non-standard types that occur automatically for any
> > application using the java client. Those uses are listed below.
> >
> > Is this an issue for anyone but me? I've suggested some ways of trying
> > to avoid these uses and would appreciate your thoughts.
> >
> > (1) The client properties sent in connection.start-ok use non-standard
> > types (ASCII_STRING).
> >
> > In AMQType, LONG_STRING, WIDE_STRING and ASCII_STRING are currently all
> > identical in implementation, differing only in the typecode used, and
> > this seems to have been sufficient for JMS compliance.
> >
> > As they seem to be equivalent, are there any objections to using only
> > LONG_STRING, which is an AMQP standard type? There seems to be little
> > point in deviating from the standard where we currently gain no benefit
> > from doing so.
> >
> > That would solve the immediate problem and also enable String message
> > properties to be used.
> >
> > (2) BasicMessagePublisher sets a property of a non-standard type
> > (BINARY) on all messages sent.
> >
> > This is the CustomJMSXProperty.JMSX_QPID_JMSDESTINATIONURL property. I
> > am not clear in what this is used for. It is currently read in
> > BasicMessageConsumer only where CLIENT_ACKNOWLEDGE mode has been set.
> > Can anyone shed a bit more light on what this property is used for, as
> > that may open up other options for getting around this issue?
> >
> > As an aside, the java implementation for the 'BINARY' type seems to use
> > a single byte for the size, whereas the proposal on the wiki specifies 4
> > bytes for the size. 256 bytes is a bit limiting for a binary type.
> >
> > The reason for sending it as binary is (as I understand it) efficiency.
> > The value is composed of different parts, and parsing these on the
> > receiver is faster and simpler using raw bytes.
> >
> > Of course in terms of the wire transfer this would not rule out the use
> > of LONG_STRING, but the FieldTable class converts any values marked as
> > LONG_STRING into java String objects and reconverting that to a byte
> > array would have incurred some unnecessary overhead.
> >
> > We could alter this so that FieldTable holds LONG_STRING values as byte
> > arrays, and the conversion to and from strings is done separately in the
> > setters and getters that use the String type. We could then allow
> > alternate setters and getters that accessed the raw bytes (these would
> > be separate also from the getBytes()/setBytes() which have to use a
> > separate type identifier for JMS compliance). Any comments on that
> > approach?
> >
> > [*] I will update the c++ broker at some point to also recognise the
> > extended types which will at least allow interoperability within the
> > qpid project.
> >
> > [**] The basic.consume method has a non-standard field, but as this has
> > been added in 0-9, once we move to that version this issue will cease to
> > concern us. One side effect worth pointing out though is that the M1
> > release will not be interoperable with the current trunk.
> >
>
>
Re: [java] AMQP compliance and the Java client
Posted by Robert Godfrey <ro...@gmail.com>.
To shed some light on the use of the custom property...
It is used to support the notion of getJMSDestination() on a JMSMessage
That is JMS requires us to know the original destination (in JMS terms) that
the message was sent to, We originally did this by sending the BindingURL
as a long string, however this proved to be very inefficient.
The current solution of sending a byte-encoded representation of the
Destination is still not correct. In general we need to think through the
whole notion of what a destination is in QPID / AMQP.
We probably need a change at the protocol level to ensure that the original
intended destination is included in the header, but for this we need to be
clear on what a destination is. It cannot simply be exchange and routing
key, as we need to consider the case of topologies of brokers wired
together. Thus we need a globally unique destination name to provide
correct equality semantics.
- Rob
On 17/01/07, Gordon Sim <gs...@redhat.com> wrote:
>
> Achieving JMS compliance has necessitated some non-standard protocol
> extensions/alterations. To use all JMS features, only a broker that
> supports these extensions/alterations can be used (currently only the
> java broker[*]). Further, the java client can not at present be used in
> *any* capacity with a broker that does not support these extensions.
>
> The key issue is the extended value types for field tables[**] and in
> particular uses of non-standard types that occur automatically for any
> application using the java client. Those uses are listed below.
>
> Is this an issue for anyone but me? I've suggested some ways of trying
> to avoid these uses and would appreciate your thoughts.
>
> (1) The client properties sent in connection.start-ok use non-standard
> types (ASCII_STRING).
>
> In AMQType, LONG_STRING, WIDE_STRING and ASCII_STRING are currently all
> identical in implementation, differing only in the typecode used, and
> this seems to have been sufficient for JMS compliance.
>
> As they seem to be equivalent, are there any objections to using only
> LONG_STRING, which is an AMQP standard type? There seems to be little
> point in deviating from the standard where we currently gain no benefit
> from doing so.
>
> That would solve the immediate problem and also enable String message
> properties to be used.
>
> (2) BasicMessagePublisher sets a property of a non-standard type
> (BINARY) on all messages sent.
>
> This is the CustomJMSXProperty.JMSX_QPID_JMSDESTINATIONURL property. I
> am not clear in what this is used for. It is currently read in
> BasicMessageConsumer only where CLIENT_ACKNOWLEDGE mode has been set.
> Can anyone shed a bit more light on what this property is used for, as
> that may open up other options for getting around this issue?
>
> As an aside, the java implementation for the 'BINARY' type seems to use
> a single byte for the size, whereas the proposal on the wiki specifies 4
> bytes for the size. 256 bytes is a bit limiting for a binary type.
>
> The reason for sending it as binary is (as I understand it) efficiency.
> The value is composed of different parts, and parsing these on the
> receiver is faster and simpler using raw bytes.
>
> Of course in terms of the wire transfer this would not rule out the use
> of LONG_STRING, but the FieldTable class converts any values marked as
> LONG_STRING into java String objects and reconverting that to a byte
> array would have incurred some unnecessary overhead.
>
> We could alter this so that FieldTable holds LONG_STRING values as byte
> arrays, and the conversion to and from strings is done separately in the
> setters and getters that use the String type. We could then allow
> alternate setters and getters that accessed the raw bytes (these would
> be separate also from the getBytes()/setBytes() which have to use a
> separate type identifier for JMS compliance). Any comments on that
> approach?
>
> [*] I will update the c++ broker at some point to also recognise the
> extended types which will at least allow interoperability within the
> qpid project.
>
> [**] The basic.consume method has a non-standard field, but as this has
> been added in 0-9, once we move to that version this issue will cease to
> concern us. One side effect worth pointing out though is that the M1
> release will not be interoperable with the current trunk.
>
Re: [java] client patch for review & comments
Posted by Robert Greig <ro...@gmail.com>.
On 17/01/07, Gordon Sim <gs...@redhat.com> wrote:
> Attached is a patch that I would like to make to the Java client
> (including some changes to the common module).
>
> It does the following:
>
> (i) uses LONG_STRING in place of WIDE_STRING for properties set through
> FieldTable.setString() as these appear to all be equivalent (apart from
> the type code)
This should be fine. WIDE_STRING needs some work to be useful since
there needs to be some kind of agreement on connection establishment
on the encoding used (you may recall we discussed this a while ago).
> (ii) uses setString instead of setAsciiString in creation of the
> connection.start-ok frames client properties
Again this looks fine to me. It was originally setString but in a
confused moment I think I changed it to asciiString :-|
> (iii) uses 4 bytes for the size of the BINARY value type as per the spec
> posted on the wiki
Yes, this is a bug.
RG
Re: [java] client patch for review & comments
Posted by Robert Godfrey <ro...@gmail.com>.
Hi Gordon
Thanks for this, let me take a look when I get back to my hotel... At first
glance the idea seems fine. It will at least stop interop issues for
clients who do not explictly use any other JMS headers.
Cheers,
Rob
[java] client patch for review & comments
Posted by Gordon Sim <gs...@redhat.com>.
Attached is a patch that I would like to make to the Java client
(including some changes to the common module).
It does the following:
(i) uses LONG_STRING in place of WIDE_STRING for properties set through
FieldTable.setString() as these appear to all be equivalent (apart from
the type code)
(ii) uses setString instead of setAsciiString in creation of the
connection.start-ok frames client properties
(iii) uses 4 bytes for the size of the BINARY value type as per the spec
posted on the wiki
I have a patch for the c++ broker to add support for the BINARY value
type and with these changes, that allows the topic test at least to pass
using java client and c++ broker). (I would prefer to have that pass
without the use of BINARY at all, but will leave that for later).
If anyone has any objections to the attached patch, let me know. In
particular if it will have any impact on the JMS TCK. Otherwise I will
check this in.
Re: [java] AMQP compliance and the Java client
Posted by Robert Greig <ro...@gmail.com>.
On 18/01/07, Gordon Sim <gs...@redhat.com> wrote:
> Robert Greig wrote:
>
> But the current trunk is still tracking 0-8 I think (i.e. thats the
> version of the spec in use and echoed on connection handshaking).
Ah ok, in that case I think that should be changed. I certainly don't
view the trunk as tracking 0-8.
> > e.g. let us assume for the purposes of this discussion that field
> > table type enhancements is in AMQP 0-10. In that case I would not view
> > it as a bug that trunk java does not interop with trunk C++ at a given
> > point in time (although there is obviously a task there for C++ to
> > implement that change).
>
> If the c++ code is based on 0-10 (i.e. that is the spec it builds off
> and announces on connection startup) and doesn't support all the types
> then yes, that would in my view imply a 'known bug' in the c++ code,
> preventing full use of the protocol.
Yes.
RG
Re: [java] AMQP compliance and the Java client
Posted by Gordon Sim <gs...@redhat.com>.
Robert Greig wrote:
> On 18/01/07, Gordon Sim <gs...@redhat.com> wrote:
>
>> As the trunk is a moving target I don't think we can 'guarantee'
>> anything (not even that it builds at any point in time!). I do think we
>> should aim as far as possible to be compliant in at least a basic sense
>> with the specification version in use.
>
> Yes, I think the problems have been caused by a lack of clarity of
> what we are tracking/heading towards. We are notionally heading
> towards 0-9 but 0-9 does not include everything we need to be JMS
> compatible, and JMS compatibility was a goal for qpid's next release.
But the current trunk is still tracking 0-8 I think (i.e. thats the
version of the spec in use and echoed on connection handshaking).
> e.g. let us assume for the purposes of this discussion that field
> table type enhancements is in AMQP 0-10. In that case I would not view
> it as a bug that trunk java does not interop with trunk C++ at a given
> point in time (although there is obviously a task there for C++ to
> implement that change).
If the c++ code is based on 0-10 (i.e. that is the spec it builds off
and announces on connection startup) and doesn't support all the types
then yes, that would in my view imply a 'known bug' in the c++ code,
preventing full use of the protocol.
Re: [java] AMQP compliance and the Java client
Posted by Robert Greig <ro...@gmail.com>.
On 18/01/07, Gordon Sim <gs...@redhat.com> wrote:
> As the trunk is a moving target I don't think we can 'guarantee'
> anything (not even that it builds at any point in time!). I do think we
> should aim as far as possible to be compliant in at least a basic sense
> with the specification version in use.
Yes, I think the problems have been caused by a lack of clarity of
what we are tracking/heading towards. We are notionally heading
towards 0-9 but 0-9 does not include everything we need to be JMS
compatible, and JMS compatibility was a goal for qpid's next release.
I think that we are in a position where our next release of qpid (i.e.
M-release) can only sensibly be with 0-10.
> I would view anything that breaks compatibility (as opposed to anything
> that extends functionality in a non-standard way) as a known bug. It is
> to be expected that there may be known bugs on the trunk at any time,
> but the aim should always be to have these clearly highlighted and a
> plan in place to fix them as soon as practicable.
Unless that is an incompatibility introduced by a breaking change in
the spec we are tracking towards?
e.g. let us assume for the purposes of this discussion that field
table type enhancements is in AMQP 0-10. In that case I would not view
it as a bug that trunk java does not interop with trunk C++ at a given
point in time (although there is obviously a task there for C++ to
implement that change).
> Agreed. (It may be useful nearer the 1.0 release to try an validate any
> mechanisms we might have created for multi-version support by
> implementing two similar versions, but that would be more for our
> benefit than for our users).
Yes, a clear analysis of our multi-version strategy is almost
certainly required...
RG
Re: [java] AMQP compliance and the Java client
Posted by Gordon Sim <gs...@redhat.com>.
Robert Greig wrote:
> My own view is that we must not lose sight of the fact that qpid is
> tracking a specification that is still evolving rapidly - currently
> version 0.8 with 0-9 in progress. Also the qpid codebase itself is
> being changed a lot, and we have only had one milestone release. Given
> that rate of change, is it sensible for qpid *trunk* to track an AMQP
> specification? Or even offer any guarantees of interoperability?
I think we are by definition 'tracking' some version of the
specification as we rely on the xml section for code generation (dynamic
or otherwise), the question is how compliant we are with respect to the
version currently in use. (An interesting aside is whether we are in
violation of the copyright if we edit the xml spec after it is published?)
As the trunk is a moving target I don't think we can 'guarantee'
anything (not even that it builds at any point in time!). I do think we
should aim as far as possible to be compliant in at least a basic sense
with the specification version in use.
> How do the following rules sound to people:
>
> 1) Qpid releases will support a particular published version of the
> AMQP specification.
Agreed, as far as feasible and we should aim to document any gaps or
failings in support for each release.
> 2) Qpid trunk should be considered a work in progress that may not
> support a published AMQP specification. People using trunk are using
> bleeding edge software.
I would view anything that breaks compatibility (as opposed to anything
that extends functionality in a non-standard way) as a known bug. It is
to be expected that there may be known bugs on the trunk at any time,
but the aim should always be to have these clearly highlighted and a
plan in place to fix them as soon as practicable.
> 3) Up to AMQP 1.0 (whenever that is published) Qpid will not offer
> backwards compatibility between versions. After AMQP 1.0 is released,
> qpid releases will be backwards compatible for major versions of AMQP.
Agreed. (It may be useful nearer the 1.0 release to try an validate any
mechanisms we might have created for multi-version support by
implementing two similar versions, but that would be more for our
benefit than for our users).
Re: [java] AMQP compliance and the Java client
Posted by Robert Greig <ro...@gmail.com>.
On 17/01/07, Gordon Sim <gs...@redhat.com> wrote:
> Achieving JMS compliance has necessitated some non-standard protocol
> extensions/alterations. To use all JMS features, only a broker that
> supports these extensions/alterations can be used (currently only the
> java broker[*]). Further, the java client can not at present be used in
> *any* capacity with a broker that does not support these extensions.
I think it is worth separating the particular issue in this case (i.e.
the changes made to field table and so on) so that we as a group can
try to agree on some general principles and rules for qpid's
relationship with AMQP.
My own view is that we must not lose sight of the fact that qpid is
tracking a specification that is still evolving rapidly - currently
version 0.8 with 0-9 in progress. Also the qpid codebase itself is
being changed a lot, and we have only had one milestone release. Given
that rate of change, is it sensible for qpid *trunk* to track an AMQP
specification? Or even offer any guarantees of interoperability?
How do the following rules sound to people:
1) Qpid releases will support a particular published version of the
AMQP specification.
2) Qpid trunk should be considered a work in progress that may not
support a published AMQP specification. People using trunk are using
bleeding edge software.
3) Up to AMQP 1.0 (whenever that is published) Qpid will not offer
backwards compatibility between versions. After AMQP 1.0 is released,
qpid releases will be backwards compatible for major versions of AMQP.
RG
Re: [java] AMQP compliance and the Java client
Posted by Robert Godfrey <ro...@gmail.com>.
>
> Question and suggestion about this general topic:
Why weren't the new types simply packed inside a standard longstr?
>
> I see the value of adding new framing types like wide strings that would
> be of general use to any AMQP implementation, however I don't see much
> value in producing a non-interoperable AMQP implementation.
Obviously one can pack any type inside a longstr, including a FieldTable...
but just because one can do something... ;-)
Seriously, although I wasn't party to the original proposal on additional
types, it seems to me that it is a better solution to define new types than
to hack these distinct types into longstr. There does not appear to me to
be a huge development cost in adding these to the protocol (mostly these can
be treated as pass-thru by the broker), and if we are defining a standard
way of implementing JMS compliance then we need a way to differentiate
between these types, and the alternative would be to define standard
encodings inside a longstr, which seems needlessly inefficient. I would
think that one of our goals would be to make the protocol as efficient as
possible - every byte we can save, we should.
I agree that a client should be capable of working in strict AMQP mode where
these extensions are not used. However this would be at the cost
(currently) of JMS compliance [there are other non-standard extensions to
the protocol other than just the FieldTable types - if it were just the
FieldTable types I would agree that it would be an unnecessary deviation
from the spec. However there are bigger issues.].
Until we get changes to the protocol agreed, we can be AMQP compliant, or
JMS compliant, but not both simultaneously (on a given connection).
2) Any feature that does make non-standard extensions to the protocol
> should ensure that it *never* sends such extensions to a peer unless it
> understands such extensions. There is a standard field table passed
> during connection setup that would allow implementations to identify
> themselves for such purposes.
How can we determine that when the destination of a given message is not
known when it is sent? Are we proposing that the broker is responsible for
re-encoding the message?
As we can see in the discussion over 0-9, the protocol is in a high degree
of flux currently. I think that anybody who uses QPID at the moment has to
be aware that neither the protocol nor the product have reached the level of
stability and maturity where one can expect seemless interoperability (as
reflected by their version numbers). Therefore anyone currently deploying
QPID should be free to make the decision as to whether (for instance) JMS
compliance, or interoperability with non-QPID clients is their requirement.
We also have to be very clear what (possibly partial) version on AMQP any
release is going to support.
Until we approach 1-0 I do not believe it is wrong to implement something
we believe will become part of the protocol (and I believe this is the path
we should take when we implement the 0-9 WIP) as long as it does not
fundamentally break the ability of AMQP compliant clients to communicate
with the broker . To this point I think the Java client errs in not
providing an AMQP mode where the non-standard extensions are not used.
> 3) Any new feature of qpid that is successfully implemented using
> existing protocol features may still prompt a protocol change and a
> simpler implementation when the new protocol is published.
>
> E.g. I would prefer to have seen the current issue implemented first
> using longstr, with a propposal to the AMQP working group to add
> wide-string to the basic framing types.
I believe the new types have been put as a proposal, however we need to push
to get it adopted.
Again, I agree that we should be attempting to stay true to the protocol.
I guess my personal rules would be these:
1. We should never make any change to a QPID broker which will stop
compliant AMQP clients communicating through the broker.
2. Every QPID client should always be interoperable with every other QPID
client and the QPID broker for a defined "release".
3. It must be possible to configure the clients so that can
communicate through any compliant AMQP broker to any compliant AMQP client.
currently I think we may be breaking all three rules :-) We are certainly
breaking 2 & 3.
As we get closer to a 1-0 release of the protocol I would expect that our
rule will be there are no deviations from the protocol. Fundamentally every
deviation we make from the published protocol is *very bad*, and we should
have been documenting these more clearly.
- Rob
Re: [java] AMQP compliance and the Java client
Posted by Alan Conway <ac...@redhat.com>.
On Wed, 2007-01-17 at 12:25 +0000, Gordon Sim wrote:
> Achieving JMS compliance has necessitated some non-standard protocol
> extensions/alterations. To use all JMS features, only a broker that
> supports these extensions/alterations can be used (currently only the
> java broker[*]). Further, the java client can not at present be used in
> *any* capacity with a broker that does not support these extensions.
>
Question and suggestion about this general topic:
Why weren't the new types simply packed inside a standard longstr?
I see the value of adding new framing types like wide strings that would
be of general use to any AMQP implementation, however I don't see much
value in producing a non-interoperable AMQP implementation.
My feeling is that
1) Any new feature in Qpid should be implemented using standard
extension points in AMQP unless it is utterly unfeasible to do so, and
if that's the case there should be discussion to establish that it
really is utterly infeasible - and that discussion should spill onto the
AMQ protocol lists to highlight the shortcoming of the protocol.
2) Any feature that does make non-standard extensions to the protocol
should ensure that it *never* sends such extensions to a peer unless it
understands such extensions. There is a standard field table passed
during connection setup that would allow implementations to identify
themselves for such purposes.
3) Any new feature of qpid that is successfully implemented using
existing protocol features may still prompt a protocol change and a
simpler implementation when the new protocol is published.
E.g. I would prefer to have seen the current issue implemented first
using longstr, with a propposal to the AMQP working group to add
wide-string to the basic framing types.
Cheers,
Alan.