On 17/01/2008, Rajith Attapattu <[EMAIL PROTECTED]> wrote: > After the discussions with Martin and Robert here is what I think. > The BindingURL was used for 3 things in the code. > 1) The broker used it (apparently not anymore - which is good) > 2) ReplyTo - still the 0-8 clients use this and needs to support it. > 3) JNDI > > I propose we revamp the BindingURL to support the following use cases. So we > can have some flexibility while still using 100% pure JMS. > > 1) First and foremost we need to maintain backward compatibility to maintain > the 0-8 stuff. > > 2) Allow an AMQQueue to use a routing key different from the queue name. > > 3) Allow an AMQQueue to bind to a Fannout exchange. > > 4) Allow to bind to a queue with more than one routing key. > > The change I made have broken use case 1 slightly. I need to fix that. > Option 2 and 3 can be done with the current changes. > Option 4 needs to be thought through as it has some implications on a > producer etc. > > One suggestion is to have a list of rotingkeys. > Ex. direct://amq.direct/queueName?routingKey="rk1 del rk2 del rk3 .." > We need to find a suitable delimiter for this. > For the issue with producers, when we define a destination for the producer > we can put only one. Or if a list is there we can take the first one.
My suggestion to maintain compatibility with existing JNDI clients would be to have multiple routkingKey options taking your example: direct://amq.direct/queueName?routingKey="rk1"&routingKey="rk2&routingKey="rk3" This would allow the M2 JNDI parser to work it would end up with routingKey = rk3 but then the new parser would beable to know that there were multiple queues associated with it so it could send multiple bind requests or send multiple messages to each routingkey. On a related note I'm still not sure that the java client should automatically create queues beyond the simplistic queueName == routingKey, if it should even do that. Other JMS providers require that the queues be already created by and admin on the broker. This approach would certainly get around the client having to do any multiple routingKey configuration. If we start down the road to multiple routingKeys in JNDI then it just begs the question of how I do this: My application consumes a number of sources of data I'm lazy and just want one subscription. AMQP allows me to do this so I'd like to have my ConsumeQueue bound as follows: To Topics uk.wholesaleprices.# & us.wholesaleprices.# , Direct rk Orders. The current URL only supports binding to a single exchange so the above would have to be done with at least two JNDI queues. Perhaps the solution is to have a new format that would solve any legacy JNDI support and allow for future compatibility. A sequence of 0-10 ReplyTo Formatted values perhaps. Just my thoughts Martin > Comments are critisisms are equally welcomed. > > Rajith > > On Jan 17, 2008 4:05 AM, Martin Ritchie <[EMAIL PROTECTED]> wrote: > > > Rajith , > > > > The BindingURL was writing (as it is java) from the JMS point of view. > > Hence destination is where you are publishing to in JMS. Now the > > reason the wiki does not match the code is because of a problem I > > realised after implementing the original spec. The URL cannot have a > > '#' in the middle as this will prevent the URI class from correctly > > parsing it. Hence the need to have the routing_key as an option. > > > > I would also be very cautious about changing this format as it is used > > in a lot more places that the Java. I would suggest that if you do > > wish to change the format then changing the code so that it matches > > the wiki documentation would be the way to go. If you do that then a > > change will be needed to update the C++ and .NET as they both use this > > format to encode the replyTo field. > > > > Really what should happen is that the BindingURL be used solely on the > > broker for parsing the bindings defined in the configuration file and > > either a simplified version or a new format be decided for replyTo > > encoding. We used to use Q|T+RoutingKey but that limited us in the > > java to only using the built in exchanges. Perhaps a subclass of > > BindingURL could be used to only present the values required to > > perform a reply. > > > > > > On 16/01/2008, Rajith Attapattu <[EMAIL PROTECTED]> wrote: > > > folks, > > > > > > I see two minor issues with the AMQBindingURL and AMQDestination > > > The binding URL is defined as follows. > > > > > <exch_class>://<exch_name>/[<destination>]/[<queue>]?<option>='<value>'[,<option>='<value>']* > > > RoutingKey is given as a valid option (See BindingURL class). > > > > > > Then in AMQDestination we see that the constructors has a field called > > > "destinationName" (in addition to exchangeName). > > > > > > As per the AMQP spec, destination refers to the exchange you are > > publishing. > > > Therefore the binding url format is incorrect, as destination has no > > meaning > > > there. > > > It cannot be the routing_key as it is given as a valid option. So I > > propose > > > we get rid of it. > > > However the documentation here is correct, but sadly not reflected in > > the > > > code properly. > > > http://cwiki.apache.org/qpid/bindingurlformat.html > > > > > > Also in AMQDestination, destinationName is used as the routingKey which > > is > > > creating confusion and it is also semantically wrong. > > > The field destinationName should refer to the exchange we are > > publishing. > > > But we already have a field named "exchangeName". > > > So I renamed the field destination to routingKey and modified the code > > > accordingly in both AMQQueue and AMQTopic. > > > > > > -- > > > Regards, > > > > > > Rajith Attapattu > > > Red Hat > > > blog: http://rajith.2rlabs.com/ > > > > > > > > > -- > > Martin Ritchie > > > > > > -- > Regards, > > Rajith Attapattu > Red Hat > blog: http://rajith.2rlabs.com/ > -- Martin Ritchie
