qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Godfrey <rob.j.godf...@gmail.com>
Subject Re: Address validation Queues vs Topics
Date Tue, 28 Feb 2012 09:01:19 GMT
As an aside, I have been labeling the open Java Client JIRAs so its
easier to pick out clusters of JIRAs that can be worked on together /
see where the real pain points are.  A quick report on open JIRAs per

17 - addressing
 9 - failover
 9 - exception-handling
 4 - deadlock
 3 - timestamp
 3 - possibly_complete
 3 - message-credit
 3 - jms-compliance
 2 - serialization
 2 - documentation
 1 - examples
 1 - browsing
 1 - amqp_compliance

Addressing covers anything to do with Destinations (ADDR or BURL) but
is clearly the major pain point... Rajith - I know you were working on
a patch for this... what is the status of this work?


On 28 February 2012 09:19, Rob Godfrey <rob.j.godfrey@gmail.com> wrote:
> On 28 February 2012 05:37, Rajith Attapattu <rajith77@gmail.com> wrote:
>> If the "queue" and "topic" qualifiers are used then I guess it makes
>> it really easy for us to work out the validation.
>> What are we going to do with the "destination" qualifier ?
>> Ex destination.my-dest=<address-string>
>> 1. We deprecate this and get qpid users to use one of "queue" or
>> "topic" as the administrator who writes the jndi file surely knows
>> what it's going to be.
>> 2. We create the destination but not allow it to be used with any
>> methods that require the Queue or Topic interface.
> ^^ This - it should be created as a Destination that implements
> neither Queue nor Topic.
>> 3. Attempt to figure out if the address is a Topic or a Queue based on
>> the current behaviour (as described in my first email) and then
>> convert it a Queue or Topic if the Destination object is passed to any
>> methods that require a Queue/Topic interface.
> As per my previous comment on the JIRA, I think it's not actually
> possible to determine from an address string what is a "topic" and
> what is a "queue".  I can define a "queue" which distributes the
> messages it hold to every consumer, and removes messages only when
> every current consumer has irrevocably passed that message... is this
> a "queue" or a "topic"?  From a JMS perspective it behaves exactly as
> you would expect from a topic (especially in an AMQP 1-0 scenario
> where you can create durable subscribers with durable links).  However
> from an AMQP 0-x perspective this looks like a "queue".  (Indeed on my
> AMQP 1-0 branch I have implemented exactly this type of "queue" in the
> Java broker... in a class called "Topic" :-) ). Conversely I could
> define an exchange type which for any given message will route to *at
> most one* bound queue... this "work sharing exchange" has many of the
> properties of a "queue" in JMS semantics, but looks like how we
> currently implement "topics" in AMQP 0-x.
> Given the above I think it is fruitless and indeed even incorrect to
> attempt to determine whether a given address satisfies JMS "Queue" or
> JMS "Topic" semantics based on the address itself.
> -- Rob
>> Regards,
>> Rajith
>> On Mon, Feb 27, 2012 at 11:30 PM, Rajith Attapattu <rajith77@gmail.com> wrote:
>>> As per the discussion on QPID-792, I'm moving the discussion onto the
>>> dev list under.
>>> I have attempted to summarise the current behaviour and some of the
>>> comments expressed by Rob and Robbie.
>>> Currently the clients (C++, python and JMS) resolves an address (with
>>> the 0-10 protocol) as follows.
>>> 1. If the name resolves to a queue, we treat it as a Queue
>>> 2. If the name resolves to an exchange, we treat is a Topic
>>> 3. If it doesn't resolve to either, we treat it as a Queue.
>>> Rob made the following comments
>>> "I don't think that we should be trying to do this because I'm pretty
>>> sure that it is impossible to determine what is a Queue and what is a
>>> Topic.
>>> I think the closest we can come is to say that an address that says
>>> you have to create a new temporary auto-delete exclusive queue for
>>> every consumer should be treated as a topic... but the converse is not
>>> true. As far as I am concerned the distinction between Queue and Topic
>>> is something that only the "administrator" can determine, and the code
>>> cannot determine dynamically."
>>> Robbie also expressed the following,
>>> "I also think that the (Java) client shouldnt be making gueses as to
>>> whether something is a Queue or a Topic, as I'm sure was fairly
>>> evident from previous mailings on the subject last year. If that
>>> questionable behaviour is causing pain, then we should at least
>>> consider simply not doing it. Destination is itself only the parent
>>> interface of Queue and Topic, it doesnt actually offer any methods
>>> (even the toString, though for backwards compatibility reasons
>>> admitedly) and really only serves to allow creating Topic and Queue
>>> consumers etc without having to have a specific Session type. I
>>> realise forcing users to specify queue or topic in the address string
>>> wouldnt be consistent with the other clients, but I do think its worth
>>> noting that the Java client isn't entirely consistent with the other
>>> clients for obvious reasons and trying to make it more so isnt
>>> necessarily always going to be a helpful or useful thing."
>>> Rob, further states that we could utilize the queue and topic
>>> qualifiers that is currently present in our JNDI mechanism.
>>> "I don't think the queue/topic distinction even needs to go into the
>>> address - it should only needs to be defined some way in the JNDI
>>> source
>>> e.g. in a properties file then things that begin
>>> queue.<NAME>=<address string>
>>> would be queues, and
>>> topic.<NAME>=<address string>
>>> would be topics"
>>> Regards,
>>> Rajith
>> ---------------------------------------------------------------------
>> Apache Qpid - AMQP Messaging Implementation
>> Project:      http://qpid.apache.org
>> Use/Interact: mailto:dev-subscribe@qpid.apache.org

Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org

View raw message