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
