You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Robbie Gemmell <ro...@gmail.com> on 2012/03/01 00:08:17 UTC
Re: Address validation Queues vs Topics
Ok, so actually taking a closer look at the code (oh my eyes :p), and
having been reminded of prior discussions around what a nice
addressing implementation might look like, I may have moved a lot
toward the idea of redoing things more comprehensively than I was
thinking earlier on. With the aim of getting this stuff working in a
far more maintainable way and allowing us to actually carry it forward
to e.g a 1.0 client, I can see that would indeed warrant possibly
breaking things a little in order to do it properly. Consider me
onboard with dumping 'destination.' and shaking up the JNDI file as
necessary.
Robbie
On 29 February 2012 20:25, Robbie Gemmell <ro...@gmail.com> wrote:
> I understand that use of amq.topic does not imply something is a
> Topic, we actually have lots of users using Queues on amq.topic.
> However, the codebase has in many areas implied such a link and the
> JNDI lookup is once such area; if you inspect the current code for the
> JNDI stuff I think you you will be hard pressed not to see where I was
> going with that comment. We have a load of existing users using that
> code, and I think we should continue to support them where it makes
> sense and it is easy to do so. For example, I see little sense
> significantly changing the behaviour of using Binding URLs at this
> point, we should just support the behaviour it has already, as far as
> I know use of Binding URLs doesnt usually result in creation of
> Destination objects that are neither a Queue or a Topic, which is the
> major issue we are really interested in tackling here for Address
> strings whilst cleaning things up in general.
>
> I continue to fail to see how a user having to specify a node type in
> an Address string is really any different than a user specifying an
> (identical?) address string in a property that has a key prefixed with
> 'queue.' or 'topic.' instead of 'destination.' to select the type of
> Destination we construct. By asking them to select a one or the other
> via key prefix we are in fact still forcing them to specify what it is
> they want, which they could easily do in a 'destination.' entry with a
> string that specifies whether it is a queue or a topic, i.e there is
> really no significant difference. I am not saying we dont encourage
> use of the queue and topic prefixes for Address Strings, but I dont
> see the need to remove it and thus affect all the existing BURL users
> and anyone specifying an explicitly typed Address string for no good
> reason.
>
> I dont see that there is much *extra* scope for simplification than
> exists in general that would require forcing alteration of the
> existing behaviour of the JNDI file for pretty much every user who has
> ever used Qpid via a Binding URL or an Address string. The only people
> we really *need* to change their behaviour are those currently
> specifying an address string without node type into a 'destination.'
> entry. I think we can and should add the new behaviour of specifying
> Address strings via 'queue.' and 'topic.' prefixes, and fix it so
> people cant get anonymous Destinations when specifying Address strings
> via 'destination.' entries, all whilst maintaining the other
> behaviours for existing users. I dont particularly think we need to
> worry about BURL users being confused by whether they are using Queues
> or Topics given the way they are usually specified (i.e exhange and
> routing key, which is the same whether the thing on the other end is
> actually a Queue or a Topic) and constructed/used (again, check the
> JNDI related code), I think we simply leave the behaviour of those
> things untouched and rely on the fact it has been working the way it
> has for anything up to 6+ years or now and most people using them thus
> know how that works already.
>
> Robbie
>
> On 29 February 2012 19:22, Rajith Attapattu <ra...@gmail.com> wrote:
>> On Wed, Feb 29, 2012 at 12:49 PM, Robbie Gemmell
>> <ro...@gmail.com> wrote:
>>> Just to be clear, I have never been suggesting we remove
>>> 'destination.' entries from the equation. I think we should keep
>>> 'destination.' as we do have users already using it as its the only
>>> way to specify ADDRs in there,
>>
>> The changes I'm proposing includes allowing both ADDR or BURL to be
>> specified for "queue" and "topics".
>> This will result in a concrete implementation of javax.jms.Queue or
>> javax.jms.Topic being returned.
>>
>> As Rob points out, I think the pain in changing an existing
>> "destination" entry into a distinct "queue" or "topic" would force an
>> administrator to really think through the implications of the address
>> string entry.
>> We have lots of users who are confused with addressing and forcing
>> them to specify their address as a "queue" or a "topic" is going to
>> reduce a lot of pain for them down the line.
>>
>> A huge plus is the simplicity we achieve in our code base by doing this.
>>>> and its also still an important entry
>>> point for people using BURLs without the arbitary assignment to
>>> amq.topic or amq.direct exchanges. I just think we should fix it.
>>
>> I'm not exactly sure what you meant here.
>> But to clarify, amq.topic doesn't imply Topics any more than
>> amq.direct implies Queue.
>> We could do Topic style messaging using amq.topic, amq.direct,
>> amq.fanout or any custom exchange.
>>
>> The existing implementation of AMQQueue and AMQTopic is very limited
>> in that it assume amq.topic for Topics and amq.direct for Queues.
>>
>>> We should make people using it with ADDRs specify what type of node
>>> they desire, but theres no reason not to let any users who are already
>>> doing that or anyone using BURLs just continue to have their code keep
>>> working. Only the users using ADDRs and 'destination.' who currently
>>> arent setting a node type would need to adjust, which they would all
>>> have to anyway if we ever removed it in favour of the other two
>>> varieties.
>>
>> As for backwards compatibility,
>> Well for ADDR we can throw an exception unless a type is specified.
>>
>> How do you propose we tackle BURL ?
>> Choose Queue or Topic based on the type of exchange being used ?
>> What if they use a custom exchange? how would we determine the type ?
>> This amounts to the magic we are already doing with address string
>> albeit with not so stellar results with TCK failures etc....
>> Instead of us trying to solve those headaches in the code, lets
>> simplify it by asking the administrator to make a decision.
>>
>> Even if we allow "destination" for backwards compatibility, I'm
>> strongly in favour of deprecating "destination" and making it quite
>> clear in release notes and documentation.
>>
>> Again the pain of having to deal with Queue vs Topic is best handled
>> at configuration time by an administrator than us trying to do the
>> magic in the code.
>>
>> Regards,
>>
>> Rajith
>>
>>> Robbie
>>>
>>> On 29 February 2012 15:46, Rajith Attapattu <ra...@gmail.com> wrote:
>>>> 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
>>>> <ro...@gmail.com> wrote:
>>>>> On 28 February 2012 17:35, Rajith Attapattu <ra...@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 <ra...@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 <ro...@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 <ro...@gmail.com> wrote:
>>>>>>>>> On 28 February 2012 05:37, Rajith Attapattu <ra...@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 <ra...@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-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
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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
>>>
>>
>> ---------------------------------------------------------------------
>> 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
Re: Address validation Queues vs Topics
Posted by Rajith Attapattu <ra...@gmail.com>.
On Wed, Feb 29, 2012 at 6:08 PM, Robbie Gemmell
<ro...@gmail.com> wrote:
> Ok, so actually taking a closer look at the code (oh my eyes :p), and
> having been reminded of prior discussions around what a nice
> addressing implementation might look like, I may have moved a lot
> toward the idea of redoing things more comprehensively than I was
> thinking earlier on. With the aim of getting this stuff working in a
> far more maintainable way and allowing us to actually carry it forward
> to e.g a 1.0 client, I can see that would indeed warrant possibly
> breaking things a little in order to do it properly. Consider me
> onboard with dumping 'destination.' and shaking up the JNDI file as
> necessary.
Thanks you sir !
Let me post the code into a branch asap.
Rajith
> Robbie
>
> On 29 February 2012 20:25, Robbie Gemmell <ro...@gmail.com> wrote:
>> I understand that use of amq.topic does not imply something is a
>> Topic, we actually have lots of users using Queues on amq.topic.
>> However, the codebase has in many areas implied such a link and the
>> JNDI lookup is once such area; if you inspect the current code for the
>> JNDI stuff I think you you will be hard pressed not to see where I was
>> going with that comment. We have a load of existing users using that
>> code, and I think we should continue to support them where it makes
>> sense and it is easy to do so. For example, I see little sense
>> significantly changing the behaviour of using Binding URLs at this
>> point, we should just support the behaviour it has already, as far as
>> I know use of Binding URLs doesnt usually result in creation of
>> Destination objects that are neither a Queue or a Topic, which is the
>> major issue we are really interested in tackling here for Address
>> strings whilst cleaning things up in general.
>>
>> I continue to fail to see how a user having to specify a node type in
>> an Address string is really any different than a user specifying an
>> (identical?) address string in a property that has a key prefixed with
>> 'queue.' or 'topic.' instead of 'destination.' to select the type of
>> Destination we construct. By asking them to select a one or the other
>> via key prefix we are in fact still forcing them to specify what it is
>> they want, which they could easily do in a 'destination.' entry with a
>> string that specifies whether it is a queue or a topic, i.e there is
>> really no significant difference. I am not saying we dont encourage
>> use of the queue and topic prefixes for Address Strings, but I dont
>> see the need to remove it and thus affect all the existing BURL users
>> and anyone specifying an explicitly typed Address string for no good
>> reason.
>>
>> I dont see that there is much *extra* scope for simplification than
>> exists in general that would require forcing alteration of the
>> existing behaviour of the JNDI file for pretty much every user who has
>> ever used Qpid via a Binding URL or an Address string. The only people
>> we really *need* to change their behaviour are those currently
>> specifying an address string without node type into a 'destination.'
>> entry. I think we can and should add the new behaviour of specifying
>> Address strings via 'queue.' and 'topic.' prefixes, and fix it so
>> people cant get anonymous Destinations when specifying Address strings
>> via 'destination.' entries, all whilst maintaining the other
>> behaviours for existing users. I dont particularly think we need to
>> worry about BURL users being confused by whether they are using Queues
>> or Topics given the way they are usually specified (i.e exhange and
>> routing key, which is the same whether the thing on the other end is
>> actually a Queue or a Topic) and constructed/used (again, check the
>> JNDI related code), I think we simply leave the behaviour of those
>> things untouched and rely on the fact it has been working the way it
>> has for anything up to 6+ years or now and most people using them thus
>> know how that works already.
>>
>> Robbie
>>
>> On 29 February 2012 19:22, Rajith Attapattu <ra...@gmail.com> wrote:
>>> On Wed, Feb 29, 2012 at 12:49 PM, Robbie Gemmell
>>> <ro...@gmail.com> wrote:
>>>> Just to be clear, I have never been suggesting we remove
>>>> 'destination.' entries from the equation. I think we should keep
>>>> 'destination.' as we do have users already using it as its the only
>>>> way to specify ADDRs in there,
>>>
>>> The changes I'm proposing includes allowing both ADDR or BURL to be
>>> specified for "queue" and "topics".
>>> This will result in a concrete implementation of javax.jms.Queue or
>>> javax.jms.Topic being returned.
>>>
>>> As Rob points out, I think the pain in changing an existing
>>> "destination" entry into a distinct "queue" or "topic" would force an
>>> administrator to really think through the implications of the address
>>> string entry.
>>> We have lots of users who are confused with addressing and forcing
>>> them to specify their address as a "queue" or a "topic" is going to
>>> reduce a lot of pain for them down the line.
>>>
>>> A huge plus is the simplicity we achieve in our code base by doing this.
>>>>> and its also still an important entry
>>>> point for people using BURLs without the arbitary assignment to
>>>> amq.topic or amq.direct exchanges. I just think we should fix it.
>>>
>>> I'm not exactly sure what you meant here.
>>> But to clarify, amq.topic doesn't imply Topics any more than
>>> amq.direct implies Queue.
>>> We could do Topic style messaging using amq.topic, amq.direct,
>>> amq.fanout or any custom exchange.
>>>
>>> The existing implementation of AMQQueue and AMQTopic is very limited
>>> in that it assume amq.topic for Topics and amq.direct for Queues.
>>>
>>>> We should make people using it with ADDRs specify what type of node
>>>> they desire, but theres no reason not to let any users who are already
>>>> doing that or anyone using BURLs just continue to have their code keep
>>>> working. Only the users using ADDRs and 'destination.' who currently
>>>> arent setting a node type would need to adjust, which they would all
>>>> have to anyway if we ever removed it in favour of the other two
>>>> varieties.
>>>
>>> As for backwards compatibility,
>>> Well for ADDR we can throw an exception unless a type is specified.
>>>
>>> How do you propose we tackle BURL ?
>>> Choose Queue or Topic based on the type of exchange being used ?
>>> What if they use a custom exchange? how would we determine the type ?
>>> This amounts to the magic we are already doing with address string
>>> albeit with not so stellar results with TCK failures etc....
>>> Instead of us trying to solve those headaches in the code, lets
>>> simplify it by asking the administrator to make a decision.
>>>
>>> Even if we allow "destination" for backwards compatibility, I'm
>>> strongly in favour of deprecating "destination" and making it quite
>>> clear in release notes and documentation.
>>>
>>> Again the pain of having to deal with Queue vs Topic is best handled
>>> at configuration time by an administrator than us trying to do the
>>> magic in the code.
>>>
>>> Regards,
>>>
>>> Rajith
>>>
>>>> Robbie
>>>>
>>>> On 29 February 2012 15:46, Rajith Attapattu <ra...@gmail.com> wrote:
>>>>> 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
>>>>> <ro...@gmail.com> wrote:
>>>>>> On 28 February 2012 17:35, Rajith Attapattu <ra...@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 <ra...@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 <ro...@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 <ro...@gmail.com> wrote:
>>>>>>>>>> On 28 February 2012 05:37, Rajith Attapattu <ra...@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 <ra...@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-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
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> 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
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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