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.
- [java] AMQP compliance and the Java client Gordon Sim
-
