You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Rajith Attapattu <ra...@gmail.com> on 2013/03/11 22:04:54 UTC
Comparing two JMS Destinations created using address strings.
Hi All,
While fixing QPID-3769, I came across this issue.
There are two options for implementing the equals method (and hashcode).
1. Check the "type" and "name" to ensure they both point to the same
"destination" (which could be a queue or an exchange in pre 1.0
terms).
2. Do a comprehensive check on the internal address data structure to
ensure that all fields, properties, options are the same.
(Please note that comparing two address strings is not a good idea as
there can whitespaces).
I prefer option one and have pasted the patch as a comment on the JIRA
What do others think?
Regards,
Rajith
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Comparing two JMS Destinations created using address strings.
Posted by Gordon Sim <gs...@redhat.com>.
On 03/19/2013 04:01 PM, Rajith Attapattu wrote:
> I agree with you that it's best to return false negatives instead of
> false positives as the latter can create issues.
> I will add the subject to the equals test, at least that will cover
> some cases, but want be a complete fix.
> Do you have a suggestion for fanout, xml, headers etc ?
I wouldn't treat those as special cases. From the perspective of a
producer my-fanout/subject1 and my-fanout/subject2 are still not
equivalent, even though the exchange type does not do any subject based
filtering, as the message they will produce by default will differ.
That difference is potentially even more significant for xml and headers
exchanges.
As you say, false negatives are to probably be preferred, so any two
destinations including a subject where that subject does not match can
in my view safely be viewed as not equivalent.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Comparing two JMS Destinations created using address strings.
Posted by Robbie Gemmell <ro...@gmail.com>.
On 26 March 2013 14:26, Rafael Schloming <rh...@alum.mit.edu> wrote:
> On Tue, Mar 26, 2013 at 8:10 AM, Robbie Gemmell <robbie.gemmell@gmail.com
> >wrote:
>
> > On 25 March 2013 18:53, Rafael Schloming <rh...@alum.mit.edu> wrote:
> >
> > > I haven't been following this discussion all that closely, but I did
> > notice
> > > two things I wanted to comment on:
> > >
> > > (1) The fact that the JMS client maps all topics into the singular
> > > amq.topic exchange is kind of weird and very different from the way the
> > > other messaging clients behave.
> > >
> > > Using addresses via the messaging API in any other language would
> result
> > in
> > > each separate topic being mapped to a distinct exchange. I think there
> > is a
> > > good case that we should change this for the JMS client going forward,
> > and
> > > not just for consistency. It is a much more natural mapping between JMS
> > and
> > > AMQP 0-x in general and using separate exchanges for each topic makes
> > for a
> > > much more manageable broker.
> > >
> > >
> > I agree it would make things clearer in many regards, but I do wonder
> about
> > the support and compatibility issues with making such a transition at
> this
> > point for the long-established components like the 0-x clients. I'd be
> > tempted to suggest restricting any such major behavioural changes to
> shiny
> > new 1.0 clients.
> >
>
> Tying it to switching over to the 1.0 client makes sense if there are going
> to be other significant behavioural changes, but is that actually the case?
> Ideally shouldn't a JMS app work pretty much the same whether it is
> speaking to the broker via 0-x or 1.0?
>
Ideally it would, definitely. There are already enough slight behavioural
differences between the 0-8/9/9-1 and 0-10 codepaths of the existing client
to cause annoyance though and the 1.0 client(s) being completely separate
and entirely different (for good reasons...) mean I'm not sure that is ever
really going to be exactly the case.
That wasnt really part of my reasoning though, it was more to do with the
fact one client has an entrenched user base that might not expect such
behvioural change between otherwise fairly minorly different releases,
whereas the newer ones (that may or may not yet exist) have yet to build up
many users at all and people picking them up should really be more
accepting of change given it is in fact something entirely new.
I'm not completely against it, as I do agree it would have been a more
obvious way of doing things from the start, just putting the idea out for
discussion as to whether the gains for users of the older protocol client
actually warrants the upheaval given its been that way for say 7? years.
>
> I'm just thinking out loud here and it's been a while since I've worked in
> the JMS world so apologies if I'm not making much sense, but should we be
> preparing our users for behavioural changes, e.g. log a warning if they do
> createTopic("foo") instead of createTopic("amq.topic/foo").
>
If we decided to change it and it was just a one-time type warning that
might be ok...otherwise people using frameworks doing 'interesting'
repetition of such calls would probably not be happy about their disks
filling with logs.
I'm personally not that against the 'simple' variety as I think its
actually what many users would expect to see coming from some other
providers, and certainly most of the user code I have seen in the past does
it that way, which is probably why I'd be ok with only making this an issue
on the newer client(s). It can be a struggle getting users to make even 15
character changes to their config, so I'd be quite happy not dealing with
the outcry from changing the behaviour of their stuff somewhat noticably;
at the very least it would probably have to be configurable.
>
> Do you have in mind the full set of behavioural changes you would expect
> between the existing JMS client and the 1.0 JMS client?
>
>
Not really no, as above I was operating mostly on the basis of it often
being easier to say <new thing> works differently in regards to <x> and
gain acceptance simply because <new thing> is at least actually new and
different.
>
> >
> >
> > > (2) Forcing all destinations to be either queues or topics doesn't work
> > so
> > > well in the AMQP 1.0 world. Going forward we to be able to specify an
> > > address that refers to a node that isn't necessarily either a queue or
> a
> > > topic (e.g. it could be a specific kind of service node which doesn't
> > > behave like either). I also think it's a valid use case to be able to
> > > specify the name of something on the client and not have to know
> whether
> > it
> > > is configured on the broker to be a topic or a queue.
> > >
> > > --Rafael
> > >
> > >
> > JMS (and the Address syntax for the Messaging API, according to the docs
> > I've seen) defines Queue and Topic destinations, so whatever it actually
> > ends up being on the broker should probably be describable in those terms
> > of objects as used by the JMS client. It is specifically that I am
> > referring to when I say such things, and not whether the thing on the
> other
> > end actually is a queue/topic or an elephant.
> >
> > We are also speaking more about the 0-x client here than anything else
> here
> > which should be noted I think. Our current 0-x clients 'Address' syntax
> > implementation means that any 'Address' destination loaded from JNDI cant
> > be identified as either a Queue or Topic (without casting and using
> > Qpid-specific implementation methods) or anything else because they
> always
> > implement both of those interfaces, even when the user has specified
> which
> > they wanted up front. Its situations like that I am most keen to avoid in
> > future both for our own good and our users. If we want to allow for
> > 'unstated' types of destinations as well then so be it (this is what the
> > 1.0 JMS client does I think, gives all three options) but whenever
> someone
> > actually specifies it is a queue, it should be only a Queue object.
> >
>
> I agree it's bizarre to implement both, and I agree we should conceptually
> separate between the local JMS object and what's at the remote end.
>
>
> >
> > This stuff could be in need of some consideration when the AMQP BINDMAP
> TC
> > is looking at JMS mapping.
> >
>
> +1
>
> I just want to be sure that our JMS client allows access to the full AMQP
> world. Obviously when speaking to a JMS broker over AMQP we need to be sure
> that everything behaves as expected and the TCK passes, but I do expect
> people will want to use our JMS client to use AMQP to talk to things that
> aren't necessarily full fledged JMS brokers.
>
>
I'm fine with making it able to access everything in one way or another,
and we are certainly keen that the brokers are first and foremost AMQP
brokers which simply happen to support JMS [clients] rather than the other
way around, I just want us to be mindfull that there are simpler use cases
that don't need every feature in the book and we ensure they work as well
and in as suitably easy a fashion as people might find with other providers.
>
> >
> > (Aside:
> >
> > I'm sure someone will point out Destination is a parent on both of those
> > interfaces and is used as the parameter type on the JMS 1.1 methods. Is
> > anyone aware of any providers implementing Destination without using
> Queue
> > or Topic? Given is has no methods on it I'd be interested if anyone is
> > using it in that fashion.
> >
> > Its possibly worth noting that even the shiny JMS 2.0 annotation
> > configuration explicitly defines that you are only permitted to set the
> > interfaceType to the strings javax.jms.Queue or Java.jms.Topic.
> >
> > Further aside: if the schedule is still correct, JMS 2.0 starts its final
> > ballot today:
> >
> > http://java.net/projects/jms-spec/pages/Home
> > http://jcp.org/en/jsr/detail?id=343
> > )
> >
>
> This is an interesting aside. I'm afraid I haven't looked at JMS 2.0 yet.
> Does it define anything that would be a problem for a pure
> non-queue/non-topic Destination?
>
> --Rafael
>
The reason I actually asked above about a Destination-only implementation
is that my interpretation of the spec/interfaces has been that this was not
intended usage, and the spec really only deals with Queue and Topic based
destination objects; Destination being added in order allow things like
MessageProducer to work with either Queue or Topic without rewriting
application code for little reason. The Destination interface does talk a
lot to their provider-specific nature and using them via JNDI but thats
about it. I'm not sure if anyone is doing Destination-only, but I freely
admit that since Qpid was really my starting point with messaging and
everything else and I've obviously spent most of my time working on Qpid,
its entirely likely I just wouldnt have picked up on it if there was.
I haven't read the 'actual spec' doc for JMS 2.0 yet, but I did take a look
at a JavaOne presentation (
http://www.slideshare.net/reza_rahman/whats-new-in-java-message-service-2 )
about it and have a poke around the Javadoc a month or so ago. Destinations
seem to be untouched from 1.1, with the exception of one of the new
configuration areas intended for simplifying JEE usage allowing annotation
assisted specification of Destinations (
http://jms-spec.java.net/2.0-SNAPSHOT/apidocs/javax/jms/JMSDestinationDefinition.html).
One of the optional attribute elements is the implementation class, but the
main required element is the JMS destination interface name and there it
notes "Permitted values are javax.jms.Queue or javax.jms.Topic." (quoted
this time to avoid further typos :P), though I'm not sure that restricts
you from actually specifying other things.
Since we are on the JMS 2.0 subject,sort of, for anyone interested but not
really wanting to look through the stuff, some key changes are:
- New objects to simplify sending/receiving messages (JMSContext,
JMSProducer, JMSConsumer). Reduces the number of method calls, encapsulates
some of the previous Connection+Session+Producer objects, allows method
chaining for some things, etc.
- API support for asynchronous messaging with callbacks for completion and
errors.
- Multiple consumers are allowed on shared Topic subscriptions, within one
or across multiple JVMs.
- Delivery Delay for scheduling a future delivery.
- Message delivery count is now mandatory
- JCA adapters are now mandatory.
- Additions to simplify JEE usage, such as the annotation assisted config
mentioned above.
Re: Comparing two JMS Destinations created using address strings.
Posted by Rafael Schloming <rh...@alum.mit.edu>.
On Tue, Mar 26, 2013 at 8:10 AM, Robbie Gemmell <ro...@gmail.com>wrote:
> On 25 March 2013 18:53, Rafael Schloming <rh...@alum.mit.edu> wrote:
>
> > I haven't been following this discussion all that closely, but I did
> notice
> > two things I wanted to comment on:
> >
> > (1) The fact that the JMS client maps all topics into the singular
> > amq.topic exchange is kind of weird and very different from the way the
> > other messaging clients behave.
> >
> > Using addresses via the messaging API in any other language would result
> in
> > each separate topic being mapped to a distinct exchange. I think there
> is a
> > good case that we should change this for the JMS client going forward,
> and
> > not just for consistency. It is a much more natural mapping between JMS
> and
> > AMQP 0-x in general and using separate exchanges for each topic makes
> for a
> > much more manageable broker.
> >
> >
> I agree it would make things clearer in many regards, but I do wonder about
> the support and compatibility issues with making such a transition at this
> point for the long-established components like the 0-x clients. I'd be
> tempted to suggest restricting any such major behavioural changes to shiny
> new 1.0 clients.
>
Tying it to switching over to the 1.0 client makes sense if there are going
to be other significant behavioural changes, but is that actually the case?
Ideally shouldn't a JMS app work pretty much the same whether it is
speaking to the broker via 0-x or 1.0?
I'm just thinking out loud here and it's been a while since I've worked in
the JMS world so apologies if I'm not making much sense, but should we be
preparing our users for behavioural changes, e.g. log a warning if they do
createTopic("foo") instead of createTopic("amq.topic/foo").
Do you have in mind the full set of behavioural changes you would expect
between the existing JMS client and the 1.0 JMS client?
>
>
> > (2) Forcing all destinations to be either queues or topics doesn't work
> so
> > well in the AMQP 1.0 world. Going forward we to be able to specify an
> > address that refers to a node that isn't necessarily either a queue or a
> > topic (e.g. it could be a specific kind of service node which doesn't
> > behave like either). I also think it's a valid use case to be able to
> > specify the name of something on the client and not have to know whether
> it
> > is configured on the broker to be a topic or a queue.
> >
> > --Rafael
> >
> >
> JMS (and the Address syntax for the Messaging API, according to the docs
> I've seen) defines Queue and Topic destinations, so whatever it actually
> ends up being on the broker should probably be describable in those terms
> of objects as used by the JMS client. It is specifically that I am
> referring to when I say such things, and not whether the thing on the other
> end actually is a queue/topic or an elephant.
>
> We are also speaking more about the 0-x client here than anything else here
> which should be noted I think. Our current 0-x clients 'Address' syntax
> implementation means that any 'Address' destination loaded from JNDI cant
> be identified as either a Queue or Topic (without casting and using
> Qpid-specific implementation methods) or anything else because they always
> implement both of those interfaces, even when the user has specified which
> they wanted up front. Its situations like that I am most keen to avoid in
> future both for our own good and our users. If we want to allow for
> 'unstated' types of destinations as well then so be it (this is what the
> 1.0 JMS client does I think, gives all three options) but whenever someone
> actually specifies it is a queue, it should be only a Queue object.
>
I agree it's bizarre to implement both, and I agree we should conceptually
separate between the local JMS object and what's at the remote end.
>
> This stuff could be in need of some consideration when the AMQP BINDMAP TC
> is looking at JMS mapping.
>
+1
I just want to be sure that our JMS client allows access to the full AMQP
world. Obviously when speaking to a JMS broker over AMQP we need to be sure
that everything behaves as expected and the TCK passes, but I do expect
people will want to use our JMS client to use AMQP to talk to things that
aren't necessarily full fledged JMS brokers.
>
> (Aside:
>
> I'm sure someone will point out Destination is a parent on both of those
> interfaces and is used as the parameter type on the JMS 1.1 methods. Is
> anyone aware of any providers implementing Destination without using Queue
> or Topic? Given is has no methods on it I'd be interested if anyone is
> using it in that fashion.
>
> Its possibly worth noting that even the shiny JMS 2.0 annotation
> configuration explicitly defines that you are only permitted to set the
> interfaceType to the strings javax.jms.Queue or Java.jms.Topic.
>
> Further aside: if the schedule is still correct, JMS 2.0 starts its final
> ballot today:
>
> http://java.net/projects/jms-spec/pages/Home
> http://jcp.org/en/jsr/detail?id=343
> )
>
This is an interesting aside. I'm afraid I haven't looked at JMS 2.0 yet.
Does it define anything that would be a problem for a pure
non-queue/non-topic Destination?
--Rafael
Re: Comparing two JMS Destinations created using address strings.
Posted by Robbie Gemmell <ro...@gmail.com>.
On 25 March 2013 18:53, Rafael Schloming <rh...@alum.mit.edu> wrote:
> I haven't been following this discussion all that closely, but I did notice
> two things I wanted to comment on:
>
> (1) The fact that the JMS client maps all topics into the singular
> amq.topic exchange is kind of weird and very different from the way the
> other messaging clients behave.
>
> Using addresses via the messaging API in any other language would result in
> each separate topic being mapped to a distinct exchange. I think there is a
> good case that we should change this for the JMS client going forward, and
> not just for consistency. It is a much more natural mapping between JMS and
> AMQP 0-x in general and using separate exchanges for each topic makes for a
> much more manageable broker.
>
>
I agree it would make things clearer in many regards, but I do wonder about
the support and compatibility issues with making such a transition at this
point for the long-established components like the 0-x clients. I'd be
tempted to suggest restricting any such major behavioural changes to shiny
new 1.0 clients.
> (2) Forcing all destinations to be either queues or topics doesn't work so
> well in the AMQP 1.0 world. Going forward we to be able to specify an
> address that refers to a node that isn't necessarily either a queue or a
> topic (e.g. it could be a specific kind of service node which doesn't
> behave like either). I also think it's a valid use case to be able to
> specify the name of something on the client and not have to know whether it
> is configured on the broker to be a topic or a queue.
>
> --Rafael
>
>
JMS (and the Address syntax for the Messaging API, according to the docs
I've seen) defines Queue and Topic destinations, so whatever it actually
ends up being on the broker should probably be describable in those terms
of objects as used by the JMS client. It is specifically that I am
referring to when I say such things, and not whether the thing on the other
end actually is a queue/topic or an elephant.
We are also speaking more about the 0-x client here than anything else here
which should be noted I think. Our current 0-x clients 'Address' syntax
implementation means that any 'Address' destination loaded from JNDI cant
be identified as either a Queue or Topic (without casting and using
Qpid-specific implementation methods) or anything else because they always
implement both of those interfaces, even when the user has specified which
they wanted up front. Its situations like that I am most keen to avoid in
future both for our own good and our users. If we want to allow for
'unstated' types of destinations as well then so be it (this is what the
1.0 JMS client does I think, gives all three options) but whenever someone
actually specifies it is a queue, it should be only a Queue object.
This stuff could be in need of some consideration when the AMQP BINDMAP TC
is looking at JMS mapping.
(Aside:
I'm sure someone will point out Destination is a parent on both of those
interfaces and is used as the parameter type on the JMS 1.1 methods. Is
anyone aware of any providers implementing Destination without using Queue
or Topic? Given is has no methods on it I'd be interested if anyone is
using it in that fashion.
Its possibly worth noting that even the shiny JMS 2.0 annotation
configuration explicitly defines that you are only permitted to set the
interfaceType to the strings javax.jms.Queue or Java.jms.Topic.
Further aside: if the schedule is still correct, JMS 2.0 starts its final
ballot today:
http://java.net/projects/jms-spec/pages/Home
http://jcp.org/en/jsr/detail?id=343
)
>
> On Mon, Mar 25, 2013 at 2:22 PM, Rajith Attapattu <rajith77@gmail.com
> >wrote:
>
> > I didn't mean to let this issue slide.
> > I think as an interim solution I will add a check for subjects.
> >
> > Longer term I think (especially when we work on the new JMS client) we
> > should probably look at implementing this for Queues and Topics as
> > follows.
> > 1. Queues, if getQueueName() is the same then the destinations are equal.
> > 2. Topics, if getTopicName() is the same then the destinations are
> > equal. -- This one is a bit tricky.
> >
> > Our current Destination impl is messed up, so we can't really use this.
> > But for the new client we need to look at how we can provide a
> > meaningful context to getTopicName().
> >
> > I do agree with you that we need to force users to provide the type to
> > ensure there is no ambiguity.
> > Infact the destination proposal that I floated asked for the
> > "destination" prefix to be deprecated and use "topic." and "queue."
> > respectively.
> > Going forward any destination object that is created should be either
> > an instance of Topic or Queue, which will avoid most of these ugly
> > issue.
> >
> > Regards,
> >
> > Rajith
> >
> > On Mon, Mar 25, 2013 at 12:48 PM, Robbie Gemmell
> > <ro...@gmail.com> wrote:
> > > On 19 March 2013 16:01, Rajith Attapattu <ra...@gmail.com> wrote:
> > >
> > >> On Tue, Mar 19, 2013 at 11:15 AM, Gordon Sim <gs...@redhat.com> wrote:
> > >> > On 03/19/2013 02:55 PM, Rajith Attapattu wrote:
> > >> >>
> > >> >> Speaking with Gordon, I came to the conclusion that we first need
> to
> > >> >> figure out what we mean by Equals.
> > >> >> Does equals mean,
> > >> >>
> > >> >> If two consumers used the same destination, they should both
> receive
> > >> >> the same messages (or share, in a shared queue).
> > >> >> If two producers use the same destination, they should both send
> > >> >> messages to the same (queue/exchange ?)
> > >> >
> > >> >
> > >> > The main use of equals I can think of involves a test for
> equivalence.
> > >> E.g.
> > >> > I may have a producer for Destination A and want to know whether I
> can
> > >> use
> > >> > that instead of creating a new producer for Destination B. If A
> equals
> > >> B, I
> > >> > can assume they are equivalent, my existing producer is equivalent
> to
> > >> > creating a new one.
> > >> >
> > >> > In this case my-queue/subject1 is *not* equivalent to
> > my-queue/subject2
> > >> > (neither is my-exchange/subject1 equivalent to
> my-exchange/subject2).
> > I
> > >> > would therefore argue that the subject *is* relevant for equality.
> > >> >
> > >> > The same applies if we consider consumers rather than producers.
> > >> >
> > >> > I would also note that in this sort of use case it is safer to
> return
> > >> false
> > >> > from equals than it is to return true.
> > >>
> > >> I agree with you that it's best to return false negatives instead of
> > >> false positives as the latter can create issues.
> > >> I will add the subject to the equals test, at least that will cover
> > >> some cases, but want be a complete fix.
> > >> Do you have a suggestion for fanout, xml, headers etc ?
> > >>
> > >> Rajith
> > >>
> > >>
> > > As Gordon and I discussed in our other mails, they dont need to be
> > > considered special cases from the perspective of answering the question
> > of
> > > 'is this destination object the same as that one?'
> > >
> > > Has there been any propgress on updating the equality check? I think we
> > > need to make sure it is modified before the release now that the
> previous
> > > change is on the release branch.
> > >
> > > Robbie
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> > For additional commands, e-mail: dev-help@qpid.apache.org
> >
> >
>
Re: Comparing two JMS Destinations created using address strings.
Posted by Rajith Attapattu <ra...@gmail.com>.
On Mon, Mar 25, 2013 at 3:58 PM, Rafael Schloming <rh...@alum.mit.edu> wrote:
> On Mon, Mar 25, 2013 at 3:13 PM, Rajith Attapattu <ra...@gmail.com>wrote:
>
>> On Mon, Mar 25, 2013 at 2:53 PM, Rafael Schloming <rh...@alum.mit.edu>
>> wrote:
>> This is not the case since the time we implemented the addressing stuff.
>> (used to be the case before that).
>>
>> The JMS client behaves the same as the messaging API.
>>
>
> Are you sure? It looks to me like AMQSession.createTopic("foo") will result
> in an address of "amq.topic/foo", and I believe that's what Robbie
> suggested earlier in this thread. This would seem to very much confuse the
> notion of "topic" and "subject" as it is presented in the messaging API.
This behaviour was retained to support backwards compatibility as
request at the time.
You can certainly pass an address string to createTopic() and
createQueue() method.
>
>>
>> > (2) Forcing all destinations to be either queues or topics doesn't work
>> so
>> > well in the AMQP 1.0 world. Going forward we to be able to specify an
>> > address that refers to a node that isn't necessarily either a queue or a
>> > topic (e.g. it could be a specific kind of service node which doesn't
>> > behave like either). I also think it's a valid use case to be able to
>> > specify the name of something on the client and not have to know whether
>> it
>> > is configured on the broker to be a topic or a queue.
>>
>> JMS does provide the Destination interface, and Queues and Topics are
>> indeed special cases.
>>
>> To provide some historical context, not knowing if it's a Topic or
>> Queue has been a general issue in our code base not just for this
>> equals issue.
>> Hence the suggestions from Robbie and me about specifying a type.
>> Our products were heavily geared towards the hub-and-spoke model and
>> Queues and Topics are fundamental in this model.
>>
>
> I don't see what the "hub and spoke" model has to do with this at all.
> Pretty much every broker already supports things that don't really act like
> queues or topics.
>
> --Rafael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Comparing two JMS Destinations created using address strings.
Posted by Rob Godfrey <ro...@gmail.com>.
On 25 March 2013 20:58, Rafael Schloming <rh...@alum.mit.edu> wrote:
> On Mon, Mar 25, 2013 at 3:13 PM, Rajith Attapattu <rajith77@gmail.com
> >wrote:
>
> > On Mon, Mar 25, 2013 at 2:53 PM, Rafael Schloming <rh...@alum.mit.edu>
> > wrote:
> > JMS does provide the Destination interface, and Queues and Topics are
> > indeed special cases.
> >
> > To provide some historical context, not knowing if it's a Topic or
> > Queue has been a general issue in our code base not just for this
> > equals issue.
> > Hence the suggestions from Robbie and me about specifying a type.
> > Our products were heavily geared towards the hub-and-spoke model and
> > Queues and Topics are fundamental in this model.
> >
>
> I don't see what the "hub and spoke" model has to do with this at all.
> Pretty much every broker already supports things that don't really act like
> queues or topics.
>
> --Rafael
>
I think a more accurate explanation would be that historically the JMS
client has focused on providing a way of implementing JMS over AMQP, rather
than a way of exposing AMQP through JMS. That is to say its focus has been
JMS rather than AMQP and this is clearly something that causes issues when
attempting to interoperate with clients other than itself. This is
something we should address (no pun intended) going forward.
-- Rob
Re: Comparing two JMS Destinations created using address strings.
Posted by Rafael Schloming <rh...@alum.mit.edu>.
On Mon, Mar 25, 2013 at 3:13 PM, Rajith Attapattu <ra...@gmail.com>wrote:
> On Mon, Mar 25, 2013 at 2:53 PM, Rafael Schloming <rh...@alum.mit.edu>
> wrote:
> This is not the case since the time we implemented the addressing stuff.
> (used to be the case before that).
>
> The JMS client behaves the same as the messaging API.
>
Are you sure? It looks to me like AMQSession.createTopic("foo") will result
in an address of "amq.topic/foo", and I believe that's what Robbie
suggested earlier in this thread. This would seem to very much confuse the
notion of "topic" and "subject" as it is presented in the messaging API.
>
> > (2) Forcing all destinations to be either queues or topics doesn't work
> so
> > well in the AMQP 1.0 world. Going forward we to be able to specify an
> > address that refers to a node that isn't necessarily either a queue or a
> > topic (e.g. it could be a specific kind of service node which doesn't
> > behave like either). I also think it's a valid use case to be able to
> > specify the name of something on the client and not have to know whether
> it
> > is configured on the broker to be a topic or a queue.
>
> JMS does provide the Destination interface, and Queues and Topics are
> indeed special cases.
>
> To provide some historical context, not knowing if it's a Topic or
> Queue has been a general issue in our code base not just for this
> equals issue.
> Hence the suggestions from Robbie and me about specifying a type.
> Our products were heavily geared towards the hub-and-spoke model and
> Queues and Topics are fundamental in this model.
>
I don't see what the "hub and spoke" model has to do with this at all.
Pretty much every broker already supports things that don't really act like
queues or topics.
--Rafael
Re: Comparing two JMS Destinations created using address strings.
Posted by Rajith Attapattu <ra...@gmail.com>.
On Mon, Mar 25, 2013 at 2:53 PM, Rafael Schloming <rh...@alum.mit.edu> wrote:
> I haven't been following this discussion all that closely, but I did notice
> two things I wanted to comment on:
>
> (1) The fact that the JMS client maps all topics into the singular
> amq.topic exchange is kind of weird and very different from the way the
> other messaging clients behave.
This is not the case since the time we implemented the addressing stuff.
(used to be the case before that).
The JMS client behaves the same as the messaging API.
> Using addresses via the messaging API in any other language would result in
> each separate topic being mapped to a distinct exchange. I think there is a
> good case that we should change this for the JMS client going forward, and
> not just for consistency. It is a much more natural mapping between JMS and
> AMQP 0-x in general and using separate exchanges for each topic makes for a
> much more manageable broker.
>
> (2) Forcing all destinations to be either queues or topics doesn't work so
> well in the AMQP 1.0 world. Going forward we to be able to specify an
> address that refers to a node that isn't necessarily either a queue or a
> topic (e.g. it could be a specific kind of service node which doesn't
> behave like either). I also think it's a valid use case to be able to
> specify the name of something on the client and not have to know whether it
> is configured on the broker to be a topic or a queue.
JMS does provide the Destination interface, and Queues and Topics are
indeed special cases.
To provide some historical context, not knowing if it's a Topic or
Queue has been a general issue in our code base not just for this
equals issue.
Hence the suggestions from Robbie and me about specifying a type.
Our products were heavily geared towards the hub-and-spoke model and
Queues and Topics are fundamental in this model.
So our code base (and our mindsets to some extent) carries a bias towards this.
For the new client we should definitely look at the *Destination* from
a more a broader perspective and treat Queues and Topics as nothing
but special types of Destinations.
If we get this right, then issues such as resolving a destination,
equals implementation etc will be more clear than what it is now.
> --Rafael
>
>
> On Mon, Mar 25, 2013 at 2:22 PM, Rajith Attapattu <ra...@gmail.com>wrote:
>
>> I didn't mean to let this issue slide.
>> I think as an interim solution I will add a check for subjects.
>>
>> Longer term I think (especially when we work on the new JMS client) we
>> should probably look at implementing this for Queues and Topics as
>> follows.
>> 1. Queues, if getQueueName() is the same then the destinations are equal.
>> 2. Topics, if getTopicName() is the same then the destinations are
>> equal. -- This one is a bit tricky.
>>
>> Our current Destination impl is messed up, so we can't really use this.
>> But for the new client we need to look at how we can provide a
>> meaningful context to getTopicName().
>>
>> I do agree with you that we need to force users to provide the type to
>> ensure there is no ambiguity.
>> Infact the destination proposal that I floated asked for the
>> "destination" prefix to be deprecated and use "topic." and "queue."
>> respectively.
>> Going forward any destination object that is created should be either
>> an instance of Topic or Queue, which will avoid most of these ugly
>> issue.
>>
>> Regards,
>>
>> Rajith
>>
>> On Mon, Mar 25, 2013 at 12:48 PM, Robbie Gemmell
>> <ro...@gmail.com> wrote:
>> > On 19 March 2013 16:01, Rajith Attapattu <ra...@gmail.com> wrote:
>> >
>> >> On Tue, Mar 19, 2013 at 11:15 AM, Gordon Sim <gs...@redhat.com> wrote:
>> >> > On 03/19/2013 02:55 PM, Rajith Attapattu wrote:
>> >> >>
>> >> >> Speaking with Gordon, I came to the conclusion that we first need to
>> >> >> figure out what we mean by Equals.
>> >> >> Does equals mean,
>> >> >>
>> >> >> If two consumers used the same destination, they should both receive
>> >> >> the same messages (or share, in a shared queue).
>> >> >> If two producers use the same destination, they should both send
>> >> >> messages to the same (queue/exchange ?)
>> >> >
>> >> >
>> >> > The main use of equals I can think of involves a test for equivalence.
>> >> E.g.
>> >> > I may have a producer for Destination A and want to know whether I can
>> >> use
>> >> > that instead of creating a new producer for Destination B. If A equals
>> >> B, I
>> >> > can assume they are equivalent, my existing producer is equivalent to
>> >> > creating a new one.
>> >> >
>> >> > In this case my-queue/subject1 is *not* equivalent to
>> my-queue/subject2
>> >> > (neither is my-exchange/subject1 equivalent to my-exchange/subject2).
>> I
>> >> > would therefore argue that the subject *is* relevant for equality.
>> >> >
>> >> > The same applies if we consider consumers rather than producers.
>> >> >
>> >> > I would also note that in this sort of use case it is safer to return
>> >> false
>> >> > from equals than it is to return true.
>> >>
>> >> I agree with you that it's best to return false negatives instead of
>> >> false positives as the latter can create issues.
>> >> I will add the subject to the equals test, at least that will cover
>> >> some cases, but want be a complete fix.
>> >> Do you have a suggestion for fanout, xml, headers etc ?
>> >>
>> >> Rajith
>> >>
>> >>
>> > As Gordon and I discussed in our other mails, they dont need to be
>> > considered special cases from the perspective of answering the question
>> of
>> > 'is this destination object the same as that one?'
>> >
>> > Has there been any propgress on updating the equality check? I think we
>> > need to make sure it is modified before the release now that the previous
>> > change is on the release branch.
>> >
>> > Robbie
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: dev-help@qpid.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Comparing two JMS Destinations created using address strings.
Posted by Rafael Schloming <rh...@alum.mit.edu>.
I haven't been following this discussion all that closely, but I did notice
two things I wanted to comment on:
(1) The fact that the JMS client maps all topics into the singular
amq.topic exchange is kind of weird and very different from the way the
other messaging clients behave.
Using addresses via the messaging API in any other language would result in
each separate topic being mapped to a distinct exchange. I think there is a
good case that we should change this for the JMS client going forward, and
not just for consistency. It is a much more natural mapping between JMS and
AMQP 0-x in general and using separate exchanges for each topic makes for a
much more manageable broker.
(2) Forcing all destinations to be either queues or topics doesn't work so
well in the AMQP 1.0 world. Going forward we to be able to specify an
address that refers to a node that isn't necessarily either a queue or a
topic (e.g. it could be a specific kind of service node which doesn't
behave like either). I also think it's a valid use case to be able to
specify the name of something on the client and not have to know whether it
is configured on the broker to be a topic or a queue.
--Rafael
On Mon, Mar 25, 2013 at 2:22 PM, Rajith Attapattu <ra...@gmail.com>wrote:
> I didn't mean to let this issue slide.
> I think as an interim solution I will add a check for subjects.
>
> Longer term I think (especially when we work on the new JMS client) we
> should probably look at implementing this for Queues and Topics as
> follows.
> 1. Queues, if getQueueName() is the same then the destinations are equal.
> 2. Topics, if getTopicName() is the same then the destinations are
> equal. -- This one is a bit tricky.
>
> Our current Destination impl is messed up, so we can't really use this.
> But for the new client we need to look at how we can provide a
> meaningful context to getTopicName().
>
> I do agree with you that we need to force users to provide the type to
> ensure there is no ambiguity.
> Infact the destination proposal that I floated asked for the
> "destination" prefix to be deprecated and use "topic." and "queue."
> respectively.
> Going forward any destination object that is created should be either
> an instance of Topic or Queue, which will avoid most of these ugly
> issue.
>
> Regards,
>
> Rajith
>
> On Mon, Mar 25, 2013 at 12:48 PM, Robbie Gemmell
> <ro...@gmail.com> wrote:
> > On 19 March 2013 16:01, Rajith Attapattu <ra...@gmail.com> wrote:
> >
> >> On Tue, Mar 19, 2013 at 11:15 AM, Gordon Sim <gs...@redhat.com> wrote:
> >> > On 03/19/2013 02:55 PM, Rajith Attapattu wrote:
> >> >>
> >> >> Speaking with Gordon, I came to the conclusion that we first need to
> >> >> figure out what we mean by Equals.
> >> >> Does equals mean,
> >> >>
> >> >> If two consumers used the same destination, they should both receive
> >> >> the same messages (or share, in a shared queue).
> >> >> If two producers use the same destination, they should both send
> >> >> messages to the same (queue/exchange ?)
> >> >
> >> >
> >> > The main use of equals I can think of involves a test for equivalence.
> >> E.g.
> >> > I may have a producer for Destination A and want to know whether I can
> >> use
> >> > that instead of creating a new producer for Destination B. If A equals
> >> B, I
> >> > can assume they are equivalent, my existing producer is equivalent to
> >> > creating a new one.
> >> >
> >> > In this case my-queue/subject1 is *not* equivalent to
> my-queue/subject2
> >> > (neither is my-exchange/subject1 equivalent to my-exchange/subject2).
> I
> >> > would therefore argue that the subject *is* relevant for equality.
> >> >
> >> > The same applies if we consider consumers rather than producers.
> >> >
> >> > I would also note that in this sort of use case it is safer to return
> >> false
> >> > from equals than it is to return true.
> >>
> >> I agree with you that it's best to return false negatives instead of
> >> false positives as the latter can create issues.
> >> I will add the subject to the equals test, at least that will cover
> >> some cases, but want be a complete fix.
> >> Do you have a suggestion for fanout, xml, headers etc ?
> >>
> >> Rajith
> >>
> >>
> > As Gordon and I discussed in our other mails, they dont need to be
> > considered special cases from the perspective of answering the question
> of
> > 'is this destination object the same as that one?'
> >
> > Has there been any propgress on updating the equality check? I think we
> > need to make sure it is modified before the release now that the previous
> > change is on the release branch.
> >
> > Robbie
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org
>
>
Re: Comparing two JMS Destinations created using address strings.
Posted by Robbie Gemmell <ro...@gmail.com>.
Agreed.
One analogy I thought of involved directions. Two alternative sets of
directions from one place to another are different even though you end up
in the same place by following them.
Robbie
On 26 Mar 2013 13:08, "Gordon Sim" <gs...@redhat.com> wrote:
> On 03/25/2013 06:22 PM, Rajith Attapattu wrote:
>
>> I think as an interim solution I will add a check for subjects.
>>
>> Longer term I think (especially when we work on the new JMS client) we
>> should probably look at implementing this for Queues and Topics as
>> follows.
>> 1. Queues, if getQueueName() is the same then the destinations are equal.
>> 2. Topics, if getTopicName() is the same then the destinations are
>> equal.
>>
>
> As mentioned in an earlier response, if a Destination can contain a
> default subject then the presence of difference subjects in two Destination
> instances means they are not equivalent when creating consumers or
> producers, and in quite a significant way.
>
> I don't understand the rationale for your long term approach above. It
> seems to essentially revert to the 'type and name only' option you
> initially preferred. Why do you think that is a better long term option?
>
> If people want to merely compare the queue or topic name they can do that
> explicitly. I think the equals() method should be a stronger test for
> equivalence.
>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.**org<de...@qpid.apache.org>
> For additional commands, e-mail: dev-help@qpid.apache.org
>
>
Re: Comparing two JMS Destinations created using address strings.
Posted by Rajith Attapattu <ra...@gmail.com>.
On Tue, Mar 26, 2013 at 9:04 AM, Gordon Sim <gs...@redhat.com> wrote:
> On 03/25/2013 06:22 PM, Rajith Attapattu wrote:
>>
>> I think as an interim solution I will add a check for subjects.
>>
>> Longer term I think (especially when we work on the new JMS client) we
>> should probably look at implementing this for Queues and Topics as
>> follows.
>> 1. Queues, if getQueueName() is the same then the destinations are equal.
>> 2. Topics, if getTopicName() is the same then the destinations are
>> equal.
>
>
> As mentioned in an earlier response, if a Destination can contain a default
> subject then the presence of difference subjects in two Destination
> instances means they are not equivalent when creating consumers or
> producers, and in quite a significant way.
>
> I don't understand the rationale for your long term approach above. It seems
> to essentially revert to the 'type and name only' option you initially
> preferred. Why do you think that is a better long term option?
>
> If people want to merely compare the queue or topic name they can do that
> explicitly. I think the equals() method should be a stronger test for
> equivalence.
I guess I over simplified it here, and it isn't sufficient :(
My thinking behind this was,
1. If two producers are sending to the same Queue or two consumers
receiving from the same Queue, then they are equivalent.
In 0-10 terms, just the queue name.
But I agree with you that if you send to the same Queue with
different subjects then they are different.
2. If two producers are sending to the same Topic or two consumers
receiving from the same Topic, then they are equivalent.
In 0-10 terms, the exchange/routingkey (name/subject)combination.
Rajith
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Comparing two JMS Destinations created using address strings.
Posted by Gordon Sim <gs...@redhat.com>.
On 03/25/2013 06:22 PM, Rajith Attapattu wrote:
> I think as an interim solution I will add a check for subjects.
>
> Longer term I think (especially when we work on the new JMS client) we
> should probably look at implementing this for Queues and Topics as
> follows.
> 1. Queues, if getQueueName() is the same then the destinations are equal.
> 2. Topics, if getTopicName() is the same then the destinations are
> equal.
As mentioned in an earlier response, if a Destination can contain a
default subject then the presence of difference subjects in two
Destination instances means they are not equivalent when creating
consumers or producers, and in quite a significant way.
I don't understand the rationale for your long term approach above. It
seems to essentially revert to the 'type and name only' option you
initially preferred. Why do you think that is a better long term option?
If people want to merely compare the queue or topic name they can do
that explicitly. I think the equals() method should be a stronger test
for equivalence.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Comparing two JMS Destinations created using address strings.
Posted by Rajith Attapattu <ra...@gmail.com>.
I didn't mean to let this issue slide.
I think as an interim solution I will add a check for subjects.
Longer term I think (especially when we work on the new JMS client) we
should probably look at implementing this for Queues and Topics as
follows.
1. Queues, if getQueueName() is the same then the destinations are equal.
2. Topics, if getTopicName() is the same then the destinations are
equal. -- This one is a bit tricky.
Our current Destination impl is messed up, so we can't really use this.
But for the new client we need to look at how we can provide a
meaningful context to getTopicName().
I do agree with you that we need to force users to provide the type to
ensure there is no ambiguity.
Infact the destination proposal that I floated asked for the
"destination" prefix to be deprecated and use "topic." and "queue."
respectively.
Going forward any destination object that is created should be either
an instance of Topic or Queue, which will avoid most of these ugly
issue.
Regards,
Rajith
On Mon, Mar 25, 2013 at 12:48 PM, Robbie Gemmell
<ro...@gmail.com> wrote:
> On 19 March 2013 16:01, Rajith Attapattu <ra...@gmail.com> wrote:
>
>> On Tue, Mar 19, 2013 at 11:15 AM, Gordon Sim <gs...@redhat.com> wrote:
>> > On 03/19/2013 02:55 PM, Rajith Attapattu wrote:
>> >>
>> >> Speaking with Gordon, I came to the conclusion that we first need to
>> >> figure out what we mean by Equals.
>> >> Does equals mean,
>> >>
>> >> If two consumers used the same destination, they should both receive
>> >> the same messages (or share, in a shared queue).
>> >> If two producers use the same destination, they should both send
>> >> messages to the same (queue/exchange ?)
>> >
>> >
>> > The main use of equals I can think of involves a test for equivalence.
>> E.g.
>> > I may have a producer for Destination A and want to know whether I can
>> use
>> > that instead of creating a new producer for Destination B. If A equals
>> B, I
>> > can assume they are equivalent, my existing producer is equivalent to
>> > creating a new one.
>> >
>> > In this case my-queue/subject1 is *not* equivalent to my-queue/subject2
>> > (neither is my-exchange/subject1 equivalent to my-exchange/subject2). I
>> > would therefore argue that the subject *is* relevant for equality.
>> >
>> > The same applies if we consider consumers rather than producers.
>> >
>> > I would also note that in this sort of use case it is safer to return
>> false
>> > from equals than it is to return true.
>>
>> I agree with you that it's best to return false negatives instead of
>> false positives as the latter can create issues.
>> I will add the subject to the equals test, at least that will cover
>> some cases, but want be a complete fix.
>> Do you have a suggestion for fanout, xml, headers etc ?
>>
>> Rajith
>>
>>
> As Gordon and I discussed in our other mails, they dont need to be
> considered special cases from the perspective of answering the question of
> 'is this destination object the same as that one?'
>
> Has there been any propgress on updating the equality check? I think we
> need to make sure it is modified before the release now that the previous
> change is on the release branch.
>
> Robbie
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Comparing two JMS Destinations created using address strings.
Posted by Robbie Gemmell <ro...@gmail.com>.
On 19 March 2013 16:01, Rajith Attapattu <ra...@gmail.com> wrote:
> On Tue, Mar 19, 2013 at 11:15 AM, Gordon Sim <gs...@redhat.com> wrote:
> > On 03/19/2013 02:55 PM, Rajith Attapattu wrote:
> >>
> >> Speaking with Gordon, I came to the conclusion that we first need to
> >> figure out what we mean by Equals.
> >> Does equals mean,
> >>
> >> If two consumers used the same destination, they should both receive
> >> the same messages (or share, in a shared queue).
> >> If two producers use the same destination, they should both send
> >> messages to the same (queue/exchange ?)
> >
> >
> > The main use of equals I can think of involves a test for equivalence.
> E.g.
> > I may have a producer for Destination A and want to know whether I can
> use
> > that instead of creating a new producer for Destination B. If A equals
> B, I
> > can assume they are equivalent, my existing producer is equivalent to
> > creating a new one.
> >
> > In this case my-queue/subject1 is *not* equivalent to my-queue/subject2
> > (neither is my-exchange/subject1 equivalent to my-exchange/subject2). I
> > would therefore argue that the subject *is* relevant for equality.
> >
> > The same applies if we consider consumers rather than producers.
> >
> > I would also note that in this sort of use case it is safer to return
> false
> > from equals than it is to return true.
>
> I agree with you that it's best to return false negatives instead of
> false positives as the latter can create issues.
> I will add the subject to the equals test, at least that will cover
> some cases, but want be a complete fix.
> Do you have a suggestion for fanout, xml, headers etc ?
>
> Rajith
>
>
As Gordon and I discussed in our other mails, they dont need to be
considered special cases from the perspective of answering the question of
'is this destination object the same as that one?'
Has there been any propgress on updating the equality check? I think we
need to make sure it is modified before the release now that the previous
change is on the release branch.
Robbie
Re: Comparing two JMS Destinations created using address strings.
Posted by Robbie Gemmell <ro...@gmail.com>.
On 19 March 2013 16:01, Rajith Attapattu <ra...@gmail.com> wrote:
> On Tue, Mar 19, 2013 at 11:15 AM, Gordon Sim <gs...@redhat.com> wrote:
> > On 03/19/2013 02:55 PM, Rajith Attapattu wrote:
> >>
> >> Speaking with Gordon, I came to the conclusion that we first need to
> >> figure out what we mean by Equals.
> >> Does equals mean,
> >>
> >> If two consumers used the same destination, they should both receive
> >> the same messages (or share, in a shared queue).
> >> If two producers use the same destination, they should both send
> >> messages to the same (queue/exchange ?)
> >
> >
> > The main use of equals I can think of involves a test for equivalence.
> E.g.
> > I may have a producer for Destination A and want to know whether I can
> use
> > that instead of creating a new producer for Destination B. If A equals
> B, I
> > can assume they are equivalent, my existing producer is equivalent to
> > creating a new one.
> >
> > In this case my-queue/subject1 is *not* equivalent to my-queue/subject2
> > (neither is my-exchange/subject1 equivalent to my-exchange/subject2). I
> > would therefore argue that the subject *is* relevant for equality.
> >
> > The same applies if we consider consumers rather than producers.
> >
> > I would also note that in this sort of use case it is safer to return
> false
> > from equals than it is to return true.
>
> I agree with you that it's best to return false negatives instead of
> false positives as the latter can create issues.
> I will add the subject to the equals test, at least that will cover
> some cases, but want be a complete fix.
> Do you have a suggestion for fanout, xml, headers etc ?
>
> Rajith
>
>
As Gordon and I discussed in our other mails, they dont need to be
considered special cases from the perspective of answering the question of
'is this destination object the same as that one?'
Has there been any propgress on updating the equality check? I think we
need to make sure it is modified before the release now that the previous
change is on the release branch.
Robbie
Re: Comparing two JMS Destinations created using address strings.
Posted by Rajith Attapattu <ra...@gmail.com>.
On Tue, Mar 19, 2013 at 11:15 AM, Gordon Sim <gs...@redhat.com> wrote:
> On 03/19/2013 02:55 PM, Rajith Attapattu wrote:
>>
>> Speaking with Gordon, I came to the conclusion that we first need to
>> figure out what we mean by Equals.
>> Does equals mean,
>>
>> If two consumers used the same destination, they should both receive
>> the same messages (or share, in a shared queue).
>> If two producers use the same destination, they should both send
>> messages to the same (queue/exchange ?)
>
>
> The main use of equals I can think of involves a test for equivalence. E.g.
> I may have a producer for Destination A and want to know whether I can use
> that instead of creating a new producer for Destination B. If A equals B, I
> can assume they are equivalent, my existing producer is equivalent to
> creating a new one.
>
> In this case my-queue/subject1 is *not* equivalent to my-queue/subject2
> (neither is my-exchange/subject1 equivalent to my-exchange/subject2). I
> would therefore argue that the subject *is* relevant for equality.
>
> The same applies if we consider consumers rather than producers.
>
> I would also note that in this sort of use case it is safer to return false
> from equals than it is to return true.
I agree with you that it's best to return false negatives instead of
false positives as the latter can create issues.
I will add the subject to the equals test, at least that will cover
some cases, but want be a complete fix.
Do you have a suggestion for fanout, xml, headers etc ?
Rajith
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Comparing two JMS Destinations created using address strings.
Posted by Gordon Sim <gs...@redhat.com>.
On 03/19/2013 02:55 PM, Rajith Attapattu wrote:
> Speaking with Gordon, I came to the conclusion that we first need to
> figure out what we mean by Equals.
> Does equals mean,
>
> If two consumers used the same destination, they should both receive
> the same messages (or share, in a shared queue).
> If two producers use the same destination, they should both send
> messages to the same (queue/exchange ?)
The main use of equals I can think of involves a test for equivalence.
E.g. I may have a producer for Destination A and want to know whether I
can use that instead of creating a new producer for Destination B. If A
equals B, I can assume they are equivalent, my existing producer is
equivalent to creating a new one.
In this case my-queue/subject1 is *not* equivalent to my-queue/subject2
(neither is my-exchange/subject1 equivalent to my-exchange/subject2). I
would therefore argue that the subject *is* relevant for equality.
The same applies if we consider consumers rather than producers.
I would also note that in this sort of use case it is safer to return
false from equals than it is to return true.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Comparing two JMS Destinations created using address strings.
Posted by Rajith Attapattu <ra...@gmail.com>.
Hey Alex,
The problem is that at the time of equals being called, we wouldn't
know if it's a Topic or a Queue.
Even if it's a Topic we wouldn't know what "type" of exchange it is.
Even if we know what type of exchange it is, are we going to implement
exchange specific logic to find out equality ?
For example, what is the correct way to handle equals when the
exchange is Fanout (or Headers, XML as specified).
IMO the solution proposed by me and the solution proposed by you are
both inadequate.
Speaking with Gordon, I came to the conclusion that we first need to
figure out what we mean by Equals.
Does equals mean,
If two consumers used the same destination, they should both receive
the same messages (or share, in a shared queue).
If two producers use the same destination, they should both send
messages to the same (queue/exchange ?)
Lets try to figure this out first, and then look at a way to figure
out how best to test for that.
I'm still not quite sure about fanout, headers etc...
Regards,
Rajith
On Mon, Mar 18, 2013 at 1:59 PM, Oleksandr Rudyy <or...@gmail.com> wrote:
> Hi Rajith,
>
> I should clarify that on adding a comment about comparing subjects of
> destinations I meant topic destinations. Indeed, it does not make
> sense to compare subjects in destinations for xml exchanges, header
> exchanges and queues. However, it seems not right for me to not
> compare subject for topic destinations. Thus, I would add a subject
> comparing into equals method if subject is present in the destination.
>
> Please correct me if I am wrong, but I believe that subject is not
> present in destination for xml/header exchanges. Does it make sense to
> set subject for xml or header exchange destination? What would be the
> meaning of it in this case?
>
> Kind Regards,
> Alex
>
> On 18 March 2013 14:57, Rajith Attapattu <ra...@gmail.com> wrote:
>> IMO option two is not correct. The address string contains destination
>> information, directives for creating/deleting or verifying and other
>> directives to control behaviour.
>> For example consider the following two addresses. They refer to the same Queue.
>>
>> test-queue; {create:always}
>> test-queue;{assert:sender}
>>
>> If you use option #2, then the destinations created using those
>> strings will fail the equality test.
>> That is why I think it's more correct to do the equality test on a
>> conceptual level instead of matching every aspect of the address
>> string itself.
>>
>> As for the comments made by Alex, I don't think comparing the subject
>> is the right approach for every situation.
>> Comparing the subjects might make sense when sending to an exchange
>> (again only in certain situations), but not for queues. Also at the
>> time equals is called we may not know the 'type'. We could look at the
>> resolved property to determine this. Otherwise what are we going to do
>> ?
>>
>> What should we do for exchanges with more complicated routing
>> algorithms like Headers or XML exchange where the subject is not a
>> factor at all ? It gets complicated real soon when you look beyond the
>> simple cases.
>>
>> If you look at it from a high level pov, we send messages to either a
>> Queue or an Exchange. They are the "destinations". So one could argue
>> that if you are sending to the same "exchange" then you are sending to
>> the same destination. I think that has a stronger argument that than
>> what you are suggesting.
>>
>> How messages are matched onto queues is a function of the exchange.
>> And it's something that we should not try to factor into our equals
>> implementation.
>>
>> Regards,
>>
>> Rajith
>>
>> On Fri, Mar 15, 2013 at 6:13 PM, Robbie Gemmell
>> <ro...@gmail.com> wrote:
>>> Personally I would probably go for option 2, though I see the existing
>>> comparison (presumably for the old BindingURLs) was already similarly
>>> lacking.
>>>
>>> At the very least I think the comment Alex made on the JIRA around the
>>> 'subject' from the Address string needs to be addressed. I seem to recall
>>> from reviewing a different change at some point, I noted that not
>>> specifying an exchange within an Address made it default to use of the
>>> amq.topic exchange somewhere under the covers. That suggests that after the
>>> change which has been made, for many users session.createTopic(<simple
>>> topic name>) could have unexpectedly started returning a lot of different
>>> Topic objects that always say they are equal when they are clearly not
>>> expected to be.
>>>
>>> Robbie
>>>
>>> On 11 March 2013 21:04, Rajith Attapattu <ra...@gmail.com> wrote:
>>>
>>>> Hi All,
>>>>
>>>> While fixing QPID-3769, I came across this issue.
>>>>
>>>> There are two options for implementing the equals method (and hashcode).
>>>>
>>>> 1. Check the "type" and "name" to ensure they both point to the same
>>>> "destination" (which could be a queue or an exchange in pre 1.0
>>>> terms).
>>>>
>>>> 2. Do a comprehensive check on the internal address data structure to
>>>> ensure that all fields, properties, options are the same.
>>>>
>>>> (Please note that comparing two address strings is not a good idea as
>>>> there can whitespaces).
>>>>
>>>> I prefer option one and have pasted the patch as a comment on the JIRA
>>>>
>>>> What do others think?
>>>>
>>>> Regards,
>>>>
>>>> Rajith
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
>>>> For additional commands, e-mail: dev-help@qpid.apache.org
>>>>
>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: users-help@qpid.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Comparing two JMS Destinations created using address strings.
Posted by Oleksandr Rudyy <or...@gmail.com>.
Hi Rajith,
I should clarify that on adding a comment about comparing subjects of
destinations I meant topic destinations. Indeed, it does not make
sense to compare subjects in destinations for xml exchanges, header
exchanges and queues. However, it seems not right for me to not
compare subject for topic destinations. Thus, I would add a subject
comparing into equals method if subject is present in the destination.
Please correct me if I am wrong, but I believe that subject is not
present in destination for xml/header exchanges. Does it make sense to
set subject for xml or header exchange destination? What would be the
meaning of it in this case?
Kind Regards,
Alex
On 18 March 2013 14:57, Rajith Attapattu <ra...@gmail.com> wrote:
> IMO option two is not correct. The address string contains destination
> information, directives for creating/deleting or verifying and other
> directives to control behaviour.
> For example consider the following two addresses. They refer to the same Queue.
>
> test-queue; {create:always}
> test-queue;{assert:sender}
>
> If you use option #2, then the destinations created using those
> strings will fail the equality test.
> That is why I think it's more correct to do the equality test on a
> conceptual level instead of matching every aspect of the address
> string itself.
>
> As for the comments made by Alex, I don't think comparing the subject
> is the right approach for every situation.
> Comparing the subjects might make sense when sending to an exchange
> (again only in certain situations), but not for queues. Also at the
> time equals is called we may not know the 'type'. We could look at the
> resolved property to determine this. Otherwise what are we going to do
> ?
>
> What should we do for exchanges with more complicated routing
> algorithms like Headers or XML exchange where the subject is not a
> factor at all ? It gets complicated real soon when you look beyond the
> simple cases.
>
> If you look at it from a high level pov, we send messages to either a
> Queue or an Exchange. They are the "destinations". So one could argue
> that if you are sending to the same "exchange" then you are sending to
> the same destination. I think that has a stronger argument that than
> what you are suggesting.
>
> How messages are matched onto queues is a function of the exchange.
> And it's something that we should not try to factor into our equals
> implementation.
>
> Regards,
>
> Rajith
>
> On Fri, Mar 15, 2013 at 6:13 PM, Robbie Gemmell
> <ro...@gmail.com> wrote:
>> Personally I would probably go for option 2, though I see the existing
>> comparison (presumably for the old BindingURLs) was already similarly
>> lacking.
>>
>> At the very least I think the comment Alex made on the JIRA around the
>> 'subject' from the Address string needs to be addressed. I seem to recall
>> from reviewing a different change at some point, I noted that not
>> specifying an exchange within an Address made it default to use of the
>> amq.topic exchange somewhere under the covers. That suggests that after the
>> change which has been made, for many users session.createTopic(<simple
>> topic name>) could have unexpectedly started returning a lot of different
>> Topic objects that always say they are equal when they are clearly not
>> expected to be.
>>
>> Robbie
>>
>> On 11 March 2013 21:04, Rajith Attapattu <ra...@gmail.com> wrote:
>>
>>> Hi All,
>>>
>>> While fixing QPID-3769, I came across this issue.
>>>
>>> There are two options for implementing the equals method (and hashcode).
>>>
>>> 1. Check the "type" and "name" to ensure they both point to the same
>>> "destination" (which could be a queue or an exchange in pre 1.0
>>> terms).
>>>
>>> 2. Do a comprehensive check on the internal address data structure to
>>> ensure that all fields, properties, options are the same.
>>>
>>> (Please note that comparing two address strings is not a good idea as
>>> there can whitespaces).
>>>
>>> I prefer option one and have pasted the patch as a comment on the JIRA
>>>
>>> What do others think?
>>>
>>> Regards,
>>>
>>> Rajith
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
>>> For additional commands, e-mail: dev-help@qpid.apache.org
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Comparing two JMS Destinations created using address strings.
Posted by Robbie Gemmell <ro...@gmail.com>.
On 18 March 2013 14:57, Rajith Attapattu <ra...@gmail.com> wrote:
> IMO option two is not correct. The address string contains destination
> information, directives for creating/deleting or verifying and other
> directives to control behaviour.
> For example consider the following two addresses. They refer to the same
> Queue.
>
> test-queue; {create:always}
> test-queue;{assert:sender}
>
> If you use option #2, then the destinations created using those
> strings will fail the equality test.
> That is why I think it's more correct to do the equality test on a
> conceptual level instead of matching every aspect of the address
> string itself.
>
I guess it depends what you are actually using the equality check to look
for. Both ways have their uses in certain cases. As do getQueueName() and
getTopicName() on the JMS destination objects.
As Gordon mentioned, a good case is just answering the 'do I already have a
Destination object like this?' question, and in that case you want to be
sure and not return the wrong answer. Particularly as a lot of things might
try to cache such destination objects and look them up later (e.g. our
client in some places, and messaging frameworks using it).
> As for the comments made by Alex, I don't think comparing the subject
> is the right approach for every situation.
> Comparing the subjects might make sense when sending to an exchange
> (again only in certain situations), but not for queues. Also at the
> time equals is called we may not know the 'type'. We could look at the
> resolved property to determine this. Otherwise what are we going to do
> ?
>
> What should we do for exchanges with more complicated routing
> algorithms like Headers or XML exchange where the subject is not a
> factor at all ? It gets complicated real soon when you look beyond the
> simple cases.
>
I think that is conflating 'what happens on the broker' with 'are these
destination objects equal'. Unless the broker was to be the one doing the
comparison you cant really answer the question based on what it might do,
you can only answer it based on the details of the destination string you
have, and whether those are the same.
As for the 'we might not know the type' stuff before, I have voiced my
issues with that before as far as the JMS client is concerned and this only
reinforces my view on that; users should have to specify exactly what they
want so there is no ambiguity (or there should be a default if they dont,
as it was once documented there was, though that later got deleted as it
turned out there isn't).
> If you look at it from a high level pov, we send messages to either a
> Queue or an Exchange. They are the "destinations". So one could argue
> that if you are sending to the same "exchange" then you are sending to
> the same destination. I think that has a stronger argument that than
> what you are suggesting.
>
Users of the JMS client use Topics and Queues, and it is quite possible to
do that without knowingly writing any Address strings. Most users I liase
with still have no idea what an Exchange is for example.
The example I was probably most concerned with is the following:
Topic myTopic = session.createTopic("myTopic");
Topic yourTopic = session.createTopic("yourTopic");
Doing a toString shows these gets translated under the covers into
Addresses of:
'amq.topic'/'myTopic'; None
'amq.topic'/'yourTopic'; None
Using these Topic destinations with producers and consumers will clealy
result in completely different behaviour, but both happen to implicitly use
the amq.topic Exchange. I think you will struggle to find many users who
would consider them to be equal, and I know a lot of application code
certainly exists which would not, but by some current equals()
implementations they actually would be considered equal.
As it happens, now that I have looked it turns out the above Topic
destiantion objects continue to *not* be considered equal because
Session.createTopic() uses AMQTopic destination objects as opposed to
AMQAnyDestination objects, and AMQTopic has its own equals implementation
that when using Address strings ends up considering the exchange name and
subject (as well as verifying both are Topic destinations, because the user
had explicitly asked for a Topic destination).
Feeding similar Address strings in via JNDI such as with the config below,
it can be seen the client then does consider them to be equal, inconsistent
with the above.
destination.topic1 = amq.topic/myTopic; {node: {type:topic}}
destination.topic2 = amq.topic/yourTopic; {node: {type:topic}}
> How messages are matched onto queues is a function of the exchange.
> And it's something that we should not try to factor into our equals
> implementation.
>
I havent been arguing that we should, quite the opposite really; the client
can't really tell what the Exchange is doing to do even when armed with the
exchange name or the subject, but it can tell the user has specified
different things for those values. Whether the messages ultimately end up
in the same queue because of what the broker/exchange ends up doing with
that information when it is presented doesn't make two particular
Destination objects equal, only them having the same details does.
>
> Regards,
>
> Rajith
>
> On Fri, Mar 15, 2013 at 6:13 PM, Robbie Gemmell
> <ro...@gmail.com> wrote:
> > Personally I would probably go for option 2, though I see the existing
> > comparison (presumably for the old BindingURLs) was already similarly
> > lacking.
> >
> > At the very least I think the comment Alex made on the JIRA around the
> > 'subject' from the Address string needs to be addressed. I seem to recall
> > from reviewing a different change at some point, I noted that not
> > specifying an exchange within an Address made it default to use of the
> > amq.topic exchange somewhere under the covers. That suggests that after
> the
> > change which has been made, for many users session.createTopic(<simple
> > topic name>) could have unexpectedly started returning a lot of different
> > Topic objects that always say they are equal when they are clearly not
> > expected to be.
> >
> > Robbie
> >
> > On 11 March 2013 21:04, Rajith Attapattu <ra...@gmail.com> wrote:
> >
> >> Hi All,
> >>
> >> While fixing QPID-3769, I came across this issue.
> >>
> >> There are two options for implementing the equals method (and hashcode).
> >>
> >> 1. Check the "type" and "name" to ensure they both point to the same
> >> "destination" (which could be a queue or an exchange in pre 1.0
> >> terms).
> >>
> >> 2. Do a comprehensive check on the internal address data structure to
> >> ensure that all fields, properties, options are the same.
> >>
> >> (Please note that comparing two address strings is not a good idea as
> >> there can whitespaces).
> >>
> >> I prefer option one and have pasted the patch as a comment on the JIRA
> >>
> >> What do others think?
> >>
> >> Regards,
> >>
> >> Rajith
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> >> For additional commands, e-mail: dev-help@qpid.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
Re: Comparing two JMS Destinations created using address strings.
Posted by Rajith Attapattu <ra...@gmail.com>.
IMO option two is not correct. The address string contains destination
information, directives for creating/deleting or verifying and other
directives to control behaviour.
For example consider the following two addresses. They refer to the same Queue.
test-queue; {create:always}
test-queue;{assert:sender}
If you use option #2, then the destinations created using those
strings will fail the equality test.
That is why I think it's more correct to do the equality test on a
conceptual level instead of matching every aspect of the address
string itself.
As for the comments made by Alex, I don't think comparing the subject
is the right approach for every situation.
Comparing the subjects might make sense when sending to an exchange
(again only in certain situations), but not for queues. Also at the
time equals is called we may not know the 'type'. We could look at the
resolved property to determine this. Otherwise what are we going to do
?
What should we do for exchanges with more complicated routing
algorithms like Headers or XML exchange where the subject is not a
factor at all ? It gets complicated real soon when you look beyond the
simple cases.
If you look at it from a high level pov, we send messages to either a
Queue or an Exchange. They are the "destinations". So one could argue
that if you are sending to the same "exchange" then you are sending to
the same destination. I think that has a stronger argument that than
what you are suggesting.
How messages are matched onto queues is a function of the exchange.
And it's something that we should not try to factor into our equals
implementation.
Regards,
Rajith
On Fri, Mar 15, 2013 at 6:13 PM, Robbie Gemmell
<ro...@gmail.com> wrote:
> Personally I would probably go for option 2, though I see the existing
> comparison (presumably for the old BindingURLs) was already similarly
> lacking.
>
> At the very least I think the comment Alex made on the JIRA around the
> 'subject' from the Address string needs to be addressed. I seem to recall
> from reviewing a different change at some point, I noted that not
> specifying an exchange within an Address made it default to use of the
> amq.topic exchange somewhere under the covers. That suggests that after the
> change which has been made, for many users session.createTopic(<simple
> topic name>) could have unexpectedly started returning a lot of different
> Topic objects that always say they are equal when they are clearly not
> expected to be.
>
> Robbie
>
> On 11 March 2013 21:04, Rajith Attapattu <ra...@gmail.com> wrote:
>
>> Hi All,
>>
>> While fixing QPID-3769, I came across this issue.
>>
>> There are two options for implementing the equals method (and hashcode).
>>
>> 1. Check the "type" and "name" to ensure they both point to the same
>> "destination" (which could be a queue or an exchange in pre 1.0
>> terms).
>>
>> 2. Do a comprehensive check on the internal address data structure to
>> ensure that all fields, properties, options are the same.
>>
>> (Please note that comparing two address strings is not a good idea as
>> there can whitespaces).
>>
>> I prefer option one and have pasted the patch as a comment on the JIRA
>>
>> What do others think?
>>
>> Regards,
>>
>> Rajith
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: dev-help@qpid.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Comparing two JMS Destinations created using address strings.
Posted by Robbie Gemmell <ro...@gmail.com>.
Personally I would probably go for option 2, though I see the existing
comparison (presumably for the old BindingURLs) was already similarly
lacking.
At the very least I think the comment Alex made on the JIRA around the
'subject' from the Address string needs to be addressed. I seem to recall
from reviewing a different change at some point, I noted that not
specifying an exchange within an Address made it default to use of the
amq.topic exchange somewhere under the covers. That suggests that after the
change which has been made, for many users session.createTopic(<simple
topic name>) could have unexpectedly started returning a lot of different
Topic objects that always say they are equal when they are clearly not
expected to be.
Robbie
On 11 March 2013 21:04, Rajith Attapattu <ra...@gmail.com> wrote:
> Hi All,
>
> While fixing QPID-3769, I came across this issue.
>
> There are two options for implementing the equals method (and hashcode).
>
> 1. Check the "type" and "name" to ensure they both point to the same
> "destination" (which could be a queue or an exchange in pre 1.0
> terms).
>
> 2. Do a comprehensive check on the internal address data structure to
> ensure that all fields, properties, options are the same.
>
> (Please note that comparing two address strings is not a good idea as
> there can whitespaces).
>
> I prefer option one and have pasted the patch as a comment on the JIRA
>
> What do others think?
>
> Regards,
>
> Rajith
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org
>
>
Re: Comparing two JMS Destinations created using address strings.
Posted by Robbie Gemmell <ro...@gmail.com>.
Personally I would probably go for option 2, though I see the existing
comparison (presumably for the old BindingURLs) was already similarly
lacking.
At the very least I think the comment Alex made on the JIRA around the
'subject' from the Address string needs to be addressed. I seem to recall
from reviewing a different change at some point, I noted that not
specifying an exchange within an Address made it default to use of the
amq.topic exchange somewhere under the covers. That suggests that after the
change which has been made, for many users session.createTopic(<simple
topic name>) could have unexpectedly started returning a lot of different
Topic objects that always say they are equal when they are clearly not
expected to be.
Robbie
On 11 March 2013 21:04, Rajith Attapattu <ra...@gmail.com> wrote:
> Hi All,
>
> While fixing QPID-3769, I came across this issue.
>
> There are two options for implementing the equals method (and hashcode).
>
> 1. Check the "type" and "name" to ensure they both point to the same
> "destination" (which could be a queue or an exchange in pre 1.0
> terms).
>
> 2. Do a comprehensive check on the internal address data structure to
> ensure that all fields, properties, options are the same.
>
> (Please note that comparing two address strings is not a good idea as
> there can whitespaces).
>
> I prefer option one and have pasted the patch as a comment on the JIRA
>
> What do others think?
>
> Regards,
>
> Rajith
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org
>
>