qpid-dev mailing list archives

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

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'.

View raw message