[
https://issues.apache.org/jira/browse/QPID-803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12571196#action_12571196
]
Rafael H. Schloming commented on QPID-803:
------------------------------------------
I believe commas are valid characters in binding keys. It might be better to
use multiple parameters rather than a comma separated list, e.g.:
direct://amq.direct//myQueue?bindingkey='car'&bindingKey='van'
Also, I'm not sure the last form is necessary, and it might be confusing to
permit it since it is really two logically distinct types of URLs munged
together.
Would it be sufficient for backwards compatibility to simply permit consuming
from the first form, i.e. an URL with a single routingKey and require the
second form to be used on consume where multiple bindings are desired? I would
think in most cases when you're doing this kind of thing it would be less
confusing to use separate URLs for publish and consume anyways, and the third
form doesn't really add much in that case.
> Add multiple binding keys to a JMS Destination
> ----------------------------------------------
>
> Key: QPID-803
> URL: https://issues.apache.org/jira/browse/QPID-803
> Project: Qpid
> Issue Type: Improvement
> Components: Java Client
> Affects Versions: M3
> Reporter: Rajith Attapattu
> Fix For: M3
>
> Attachments: client.patch, common.patch
>
>
> Currently we can only bind a JMS destination using one key. But there are use
> cases where you may need to bind a queue using different binding keys to
> consume messages from different sources.
> The JMS Destination provides an abstraction to hide provider details. But
> from AMQP POV, a JMS destination has a dual nature.
> For a producer a destination represents a exchange/routingkey pair.
> For a consumer a destination should represent a queue and multiple bindings.
> (Ideally it should be an array of the following tuple
> {exchange,queue,binding}, but this is difficult to express using a simple URL
> ).
> A single destination can be used for publishing, consuming or both, so we
> need our URL to capture all 3 use cases.
> Using the 0-10 protocol we can introduce a bindingKey option that contrains a
> coma separated binding keys as follows.
> Ex: Destination used only for publishing
> ------------------------------------------------------
> destination.myQueue = direct://amq.direct//myQueue?routingkey='stock'
> Ex: Destination used only for consuming
> -------------------------------------------------------
> destination.myQueue = direct://amq.direct//myQueue?bindingkey='car,van'
> (This binds a queue to the direct exchange twice using car and van as binding
> keys)
> Ex: Destination used for both consuming and publishing
> ------------------------------------------------------------------------------
> destination.myQueue =
> direct://amq.direct//myQueue?routingKey='vehicle'&bindingkey='car,van'
> (This binds a queue to the direct exchange twice using car and van as binding
> keys for the consumer, and will when the publisher uses it, it will push a
> message to the direct exchange with the routingKey vehicle)
> This has to be backward compatible with old URLs and optimized for the common
> case where only a routing key is specified. In such a case the routiing key
> is also used as the binding key
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
