On Mon, Mar 25, 2013 at 2:53 PM, Rafael Schloming <r...@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 <rajit...@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 >> <robbie.gemm...@gmail.com> wrote: >> > On 19 March 2013 16:01, Rajith Attapattu <rajit...@gmail.com> wrote: >> > >> >> On Tue, Mar 19, 2013 at 11:15 AM, Gordon Sim <g...@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-unsubscr...@qpid.apache.org >> For additional commands, e-mail: dev-h...@qpid.apache.org >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
