qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Godfrey" <rob.j.godf...@gmail.com>
Subject Re: [java] AMQP compliance and the Java client
Date Wed, 17 Jan 2007 13:16:52 GMT
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 <gsim@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.
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message