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 08:19:25 GMT
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