Hi Olivier,

are you connecting to the broker directly or via a dispatch router?

If you are connecting to the broker directly then which virtual host you
are connecting to will depend on the values the client you used put in the
"host" field of the open frame.  The assignment of a connection to a
virtual host happens at "open" time (before you start to use the address of
any particular queue).  One virtual host in the broker is specified as the
"default" and this is the vhost used if the client does not populate the
host field of open at all.  I'm guessing that what you are seeing is that
the client is not populating host, and so both your connections are being
made to the "default" virtual host.

-- Rob

On 5 April 2017 at 11:14, Olivier Mallassi <[email protected]>
wrote:

> Hi Rob,
>
> quickly test it on the 0.7.0-snapshot and it works like a charm (did not
> check the patch on 6.0.x) on the default virtualhost from a JMS client.
> cannot make it work from python (simpleSender.py) but I have to dig into
> this.
>
> one more question on this yet. I tried the following:
> § create a globalAddressDomain [/domain/subdomain] on the default
> virtualhost. All queues are addressable through
> amqp://..:5672/domain/subdomain/queue....
> § create another virtualhost called domain2 and create a
> globalAddressDomain [/domain2/subdomain] (via POST
> http:/...8080/api/latest/virtualhost/domain2/domain2). in that case,
> cannot
> find the right url pattern to address the queue (It reminds me good old
> stuff from Apache httpd).
> While trying to send messages on amqp://..:5672/domain2/subdomain/queue2,
> got an amqp:not-found.
>
>


> Any tips on this?
>
> Regards.
>
>
> On Mon, Apr 3, 2017 at 12:02 PM, Rob Godfrey <[email protected]>
> wrote:
>
> > Apologies, there does indeed seem to be a bug here - I've raised
> QPID-7732
> > and fixed on trunk (and also attached a patch for 6.0.x).
> >
> > -- Rob
> >
> > On 31 March 2017 at 15:47, Antoine Chevin <[email protected]>
> > wrote:
> >
> > > Hello Rob,
> > >
> > > Olivier and I re-checked the global address domain feature and it seems
> > it
> > > does not resolve the global addresses correctly.
> > > When I create the queue 'queueA' on the broker and I set the
> > > globalAddressDomains to '/domain/subdomain', and then I register a
> > listener
> > > with JMS for the queue '/domain/subdomain/queueA' I get an
> > > 'amqp-not-found'.
> > > Is this expected?
> > >
> > > When I told you it worked, I think I had a zombie queue
> > > '/domain/subdomain/queueA' from my previous attempt to use '/' in queue
> > > names that made it "work" :-(.
> > >
> > > Thank you,
> > > Regards,
> > > Antoine
> > >
> > > -----Original Message-----
> > > From: Rob Godfrey [mailto:[email protected]]
> > > Sent: jeudi 2 mars 2017 16:07
> > > To: [email protected]
> > > Subject: Re: Accessing queues with '/' in name in Rest API [qpid java
> > > broker 6.0.4]
> > >
> > > On 2 March 2017 at 15:11, Antoine Chevin <[email protected]>
> > wrote:
> > >
> > > > Thank you Rob for the very detailed answer.
> > > > I saw in the code
> > > > (org.apache.qpid.server.protocol.v1_0.Session_1_0#
> remoteLinkCreation)t
> > > > hat the exchange lookup is skipped if the address starts with a '/'.
> > > > I intend to use a '/' in the beginning because I don't want the
> > > > exchange lookup.
> > > > Do you think it is a good approach?
> > > >
> > > >
> > > So the intent here is that addresses that start with "/" are considered
> > to
> > > be "global" addresses as previously described, addresses that start
> with
> > > "/" but match one of the gloabAddressDomains for the virtual host would
> > > route within the virtual host to the appropriate destination, names
> that
> > > begin with "/" but don't match one of the domains for the vhost would
> be
> > > sent via federation to a remote broker (when that code gets completed -
> > > obviously we don't have federation of that kind in the Java Broker
> > > currently).
> > >
> > > So having a name which begins with "/" may work right now, but it's
> > > reasonably likely it might break in the future.  In general I would
> avoid
> > > "/" as well as "?", ";", ",", "[", "]", "|", "(", and ")" in queue
> names.
> > >
> > > Is the plan that all your queues will start with the same /<foo>/...
> > > prefix, or will different queues have different prefixes?
> > >
> > > -- Rob
> > >
> > >
> > > > Thank you,
> > > > Regards,
> > > > Antoine
> > > >
> > > > -----Original Message-----
> > > > From: Rob Godfrey [mailto:[email protected]]
> > > > Sent: jeudi 2 mars 2017 11:09
> > > > To: [email protected]
> > > > Subject: Re: Accessing queues with '/' in name in Rest API [qpid java
> > > > broker 6.0.4]
> > > >
> > > > 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
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Reply via email to