On 2 March 2017 at 10:46, Antoine Chevin <[email protected]> wrote:
> Thank you Rob for the answer. Yes it really helps! > I noticed that addresses in the form <exchange-name>/<routing-key> are also > used with AMQP 1-0. Is it expected? > > It is part of how the Java Broker maps the AMQP 0-x Exchange/Binding/Queue model into the AMQP 1.0 address space, yes. In short when the Java Broker receives a message to an address X it first looks to see if there is an exchange X, then if there is a queue X, then if X contains a / it looks to see if the part before the / is an exchange name, and if so it sends to that exchange with the part after the / being used as the routing key. When the Java Broker receives a request to consume from an address X it first looks to see if there is a Queue X, then if there is an Exchange X (in which case it creates a temporary queue and binds with an empty binding key), and then if X contains a / and the part before the X is an exchange name it will create a temporary queue and bind that to the exchange with the binding key being the part of X after the /. Note the asymmetry on send and consume that on send it first looks for an exchange and on consume it first looks for a queue. (There are a few more rules for the globalAddressDomains and for system addresses like $management, but the above is the general rule). -- Rob > Thank you, > Regards, > Antoine > > On 1 March 2017 at 20:25, Olivier Mallassi <[email protected]> > wrote: > > > Rob, all > > > > Thank you rob for this. Could you please share more details regarding > > not using the "/"? > > > > > So there are a couple of reasons why I think not using a / makes sense: > > 1) Because of exactly the REST / encoding issue that you ran into - using > characters that often need escaping can cause a lot of issues in config > files, parameters etc... depending upon where the queue name might be used > you may end up encoding that / one, two or even more times... this gets > messy fast > > 2) Because in AMQP addressing we've been imaging the / as a separator when > using some sort of topological address scheme for addressing in federated > networks... for instance you might have a queue for orders in you dongle > department of your widget division of your company foo.com... and you might > expose that address as //foo.com/widget/dongle/orders whereas someone > connected directly to the broker would just see the queue as "orders" > (though they could also address it by its full "global" name). The Java > Broker already makes some allowance for this with the notion of > "globalAddressDomains" which you can set on the virtual host. For any > domain <foo> in the list of defined globalAddressDomains, the virtualhost > will accept messages sent <foo>/M as if it were sent to M (and the same > with consuming). > > Also note that for the Java Broker an address of the form <exchange > name>/<routing key> can be used to send / receive via AMQP 0-x > exchange/routing-key semantics. > > Hope this helps, > Rob > > > > On our side we are using amqp 1.0 that, AFAIU, promotes the "complex" > > addressing plans > > The benefit for us would be > > - alignements between our http and amqp naming conventions. It is a > > nice to have but can help lisibility > > - use "URL" to route messages. Like the samples with the > > linkroutepattern > > > > Not sure these are good ideas btw. Any feedback is welcomed > > > > Regards > > > > On Wed, 1 Mar 2017 at 18:16, Rob Godfrey <[email protected]> > wrote: > > > > > In general I'd advise against using the '/' character in queue names > > > if possible... however if you must, then you need double encode the > > > name, so "a/b" would become "a%252Fb" > > > > > > Hope this helps, > > > Rob > > > > > > On 1 March 2017 at 17:31, Antoine Chevin <[email protected]> > > wrote: > > > > > > > Hello, > > > > > > > > I created a queue with a '/' in the name. How can I access it in > > > > the > > rest > > > > api? > > > > I tried to encode the '/' with %2F but I still get a 422 "too many > > > entries > > > > in path for REST servlet queue." > > > > Can you please help? > > > > > > > > Regards, > > > > Antoine > > > > > > > > > >
