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 <[email protected]>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 > <[email protected]> wrote: > > On 19 March 2013 16:01, Rajith Attapattu <[email protected]> wrote: > > > >> On Tue, Mar 19, 2013 at 11:15 AM, Gordon Sim <[email protected]> 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: [email protected] > For additional commands, e-mail: [email protected] > >
