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