qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rajith Attapattu <rajit...@gmail.com>
Subject Re: Address validation Queues vs Topics
Date Tue, 28 Feb 2012 14:53:05 GMT

Addressing is indeed a pain point and most of it is due to grey areas
causing undesirable side effects.
I've got some work that I'm hoping to post today.

Let me first check that into a branch and then I will post a brief
outline of the design and the code in review board.
I'm hoping to wrap this up in next 2 weeks.



On Tue, Feb 28, 2012 at 4:01 AM, Rob Godfrey <rob.j.godfrey@gmail.com> wrote:
> 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
> label:
> 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?
> Cheers,
> Rob
> 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>
>>>> 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

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

View raw message