On 18 March 2013 14:57, Rajith Attapattu <[email protected]> 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
> <[email protected]> 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 <[email protected]> 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: [email protected]
> >> For additional commands, e-mail: [email protected]
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>
