On 25 March 2013 18:53, Rafael Schloming <[email protected]> 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 <[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] > > > > >
