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 <[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. > > 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 > <[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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
