Robbie,
My preference is also to just use "queue" and "topic" qualifiers and
deprecate "destination" , hence listed it as option #1 in a previous
email.
I agree with you, Rob and Gordon that the above approach is simple,
easy and more importantly less buggy.
The reason I had "destination" in my summary is due to backwards compatibility.
However I agree with Rob that the pain of deprecating the
"destination" qualifier is much less than having to deal with the
issues at the code level and the runtime issues a user might
encounter.
I will post the code soon for review.
Gentlemen, Thanks again for sharing your thoughts on this.
Regards,
Rajith
On Wed, Feb 29, 2012 at 7:46 AM, Robbie Gemmell
<robbie.gemm...@gmail.com> wrote:
> On 28 February 2012 17:35, Rajith Attapattu <rajit...@gmail.com> wrote:
>> 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}"
>
>
> This seems reasonable yes.
>
>>
>> 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.
>>
>
> This one I am less keen on. If a user specifies a type in their
> address string, then I think thats the type of object they should get,
> it shouldnt just be a hint used at some random point later when the
> Destination is used and we perform magic. If someone defined a
> 'destination.' entry saying that it is a queue, I would for example
> expect that to work when trying to create a QueueBrowser rather than
> throwing a ClassCastException. We had a user submit a patch just weeks
> ago to fix that exact use case.
>
> I think the scope for anyone getting a Destination object that didnt
> actually form a concreate Queue or Topic implementation should be
> absolutely minimal. I'd really rather prefer it didnt happen as I dont
> think it should ever be necessary for current use cases, and I'm a big
> fan of users actually having to ask for exactly what they want and
> then us trying to give them what they asked for. If what they asked
> for isnt compatible with whats found on the broker then I think thats
> when we throw an Exception telling them so, not when we start deciding
> things for them.
>
> Although JMS defines 'Destination', I really dont think it ever
> expects there to be direct implementations of it as it lists no
> methods, not even the mandated toString() 'representation of
> destination' as found on Queue and Topic. Destination was added to
> allow the new cross-domain Session objects in 1.1 to use of both
> existing Queue and Topic objects on a single session at the same time;
> there was no session.createDestination() method added along with it.
> The spec still deals with two domains, P2P and Pub/Sub, via the same
> old Queue and Topic types that now happen to also be Destinations.
>
> Do we know of any other providers who provide their users Destination
> objects which arent implementations of Queue or Topic? The idea had
> never entered my head previous to these Addressing discussions, so I
> am genuinely interested to know if there are.
>
> Robbie
>
>> 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
>>
>
> ---------------------------------------------------------------------
> 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
