Based on the discussion I would like to outline the following proposal.
I believe it reflects the consensus so far. Please correct me if
anything is amiss.
1. If the user wants to use the specialized interfaces (JMS 1.0) and
pass in either a Queue or a Topic, then they should be using "queue"
or "topic" in the jndi file.
- This will result in a Destination impl being returned, that
implements either javax.jms.Queue or javax.jms.Topic depending on the
qualifier used.
- These destinations can obviously be used with the JMS 1.1 methods
which expects the generic javax.jms.Destination.
- If a "type" is specified and is different from the qualifier
being used, we will raise an exception highlighting the discrepancy.
Ex. topic.my-topic="my-queue; {type : queue}"
2. If "destination.<jndi-name>=<address>" is used,
- This will return a Destination impl that only implements the
javax.jms.Destination.
- ** If this destination is used with JMS 1.0 methods, it will
result in a class cast exception.**
- We will not attempt to determine if the address used here is a
JMS Topic or a JMS Queue.
- If a "type" is specified with the address we will use that as a
hint when trying to check the presence of the node in the broker.
Ex if hello; {type=topic}, for 0-10 we will attempt to see if
there is an exchange in the broker named "hello" and throw an
exception if no create instructions are given.
Does this sound reasonable ? Please feel free to add/change anything I
have missed.
Regards,
Rajith
On Tue, Feb 28, 2012 at 9:53 AM, Rajith Attapattu <rajit...@gmail.com> wrote:
> Rob,
>
> 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.
>
> Regards,
>
> Rajith
>
> On Tue, Feb 28, 2012 at 4:01 AM, Rob Godfrey <rob.j.godf...@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.godf...@gmail.com> wrote:
>>> On 28 February 2012 05:37, Rajith Attapattu <rajit...@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 <rajit...@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-subscr...@qpid.apache.org
>>>>
>>
>> ---------------------------------------------------------------------
>> Apache Qpid - AMQP Messaging Implementation
>> Project: http://qpid.apache.org
>> Use/Interact: mailto:dev-subscr...@qpid.apache.org
>>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
