qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rajith Attapattu" <rajit...@gmail.com>
Subject Re: [java] AMQP compliance and the Java client
Date Wed, 17 Jan 2007 21:24:57 GMT
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.



On 1/17/07, Robert Godfrey <rob.j.godfrey@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 <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.
> >

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