qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Sim <g...@redhat.com>
Subject [java] AMQP compliance and the Java client
Date Wed, 17 Jan 2007 12:25:39 GMT
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.

Mime
View raw message