I jumped into the middle of this, sorry for irrelevant answers. Short story: I agree with you. Long story:
On Thu, 2017-04-06 at 23:38 +0200, Olivier Mallassi wrote: > I ran the following tests: > > Access the broker directly (globalAddressDomains=/domain/subdomain + > queue1) > From a JMS client, the jndi queue name must contain the "/" . > (e.g. jndi name --> queue.myQueueLookup = /domain/subdomain/queue1) > > [snip] > > > From python, the "//" is needed. > > python ./simpleSend.py -a localhost:5672//domain/subdomain/queue1 That's what I thought, good! The dispatch router has been configured with address and autoLink to /domain/subdomain/queue1. The AMQP Adress is normalized, hence > removing the first "/" [snip] I missed this part - you're talking about dispatch modifying addresses from the configuration file, not from a client. > Nos the dispatch router is configured with address and autoLink to > //domain/subdomain/queue1 (double "/") [snip] > > the //domain is removed. > The original AMQP addressing draft (from when dispatch started) defined special meaning for leading '//' - to indicate connection information like this: //host:port/addr I think that is why dispatch is removing //domain. The current AMQP addressing draft *never* includes connection information in the AMQP address - because of exactly this kind of confusion. Given the direction of the current draft and the fact that it is still not final, I agree that dispatch should not modify the configured addresses at all. I think Ganesh is already working on that so I'll stop confusing the issue. > > > > > > > On Thu, Apr 6, 2017 at 9:03 PM, Alan Conway <[email protected]> > wrote: > > On Thu, 2017-04-06 at 05:50 +0000, Olivier Mallassi wrote: > > > Or is do we add a concept of globalAddressDomains at the level of > > the > > > vhost? > > > And have something similar to the qpid broker. > > > > > > Again the need is to address amqp destination like > > > amqp://ip:5672/domain/subdomain/dest > > > amqp://ip:5672/domain2/subdomain2/dest > > > > > > > I think is confusion between an AMQP address and a URL. The URL > > grammar > > is defined by https://tools.ietf.org/html/rfc3986. Parsing this > > URL: > > > > amqp://ip:5672/domain/subdomain/dest > > > > gives: > > > > scheme="amqp" > > host="ip" > > port="5672" > > path="domain/subdomain/dest" > > > > Note there is no leading "/" on the path. The "/" in the URL is > > part of > > the URL grammar, not part of the path. Dispatch is not stripping > > the > > leading '/' - there isn't one. Dispatch could *add* a leading "/" > > but > > then you couldn't write a URL for an address that *doesn't* have a > > leading slash (e.g. the standard "$management" address would become > > "/$management") > > > > This might work: > > > > amqp://ip:5672//domain/subdomain/dest > > > > Note the double '//'. > > > > Doubling slashes looks odd but there is precedent, in standard file > > URI > > (https://tools.ietf.org/html/rfc8089) Sadly lots of people find > > that > > confusing (file:///foo vs. file://foo) but I can't think of a > > better > > solution. You could try URL percent-encoding: > > > > amqp://ip:5672/%2Fdomain/subdomain/dest > > > > But that's just hideous > > > > Note this is not a dispatch problem, it's a general "how do you > > embed > > an AMQP address in a URL problem" > > > > Apologies if I'm missing the point. > > > > > Thx > > > > > > > > > On Wed, 5 Apr 2017 at 11:48, Olivier Mallassi <olivier.mallassi@g > > mail > > > .com> wrote: > > > > Sorry Ganesh about this, my qdstat was in 0.5.0 :/ > > > > > > > > I have retried the antoine's test with the following > > configuration > > > > > > > > address { > > > > prefix: /domain/subdomain/queue1 > > > > waypoint: yes > > > > } > > > > connector { > > > > name: broker1 > > > > role: route-container > > > > host: localhost > > > > port: 5672 > > > > saslMechanisms: ANONYMOUS > > > > } > > > > autoLink { > > > > addr: /domain/subdomain/queue1 > > > > dir: in > > > > connection: broker1 > > > > } > > > > + the dir: out > > > > > > > > looking at the trace, > > > > > > > > Wed Apr 5 09:51:17 2017 AGENT (debug) Add > > > > entity: AddressEntity(distribution=balanced,identity=address/0, > > > > name=address/0, prefix=/domain/subdomain/queue1, > > > > type=org.apache.qpid.dispatch.router.config.address, > > waypoint=True) > > > > Wed Apr 5 09:51:17 2017 ROUTER_CORE (trace) Core action > > > > 'manage_create' > > > > … > > > > Wed Apr 5 09:51:17 2017 AGENT (debug) Add > > > > entity: AutoLinkEntity(addr=/domain/subdomain/queue1, > > > > connection=broker1, dir=in, identity=autoLink/0, > > name=autoLink/0, > > > > type=org.apache.qpid.dispatch.router.config.autoLink) > > > > Wed Apr 5 09:51:17 2017 ROUTER_CORE (trace) Core action > > > > 'manage_create' > > > > Wed Apr 5 09:51:17 2017 AGENT (debug) Add > > > > entity: AutoLinkEntity(addr=/domain/subdomain/queue1, connec... > > > > ... > > > > Wed Apr 5 09:51:17 2017 ROUTER_CORE (info) Auto Link Activated > > > > 'autoLink/0' on connection broker1 > > > > Wed Apr 5 09:51:17 2017 ROUTER_CORE (info) Auto Link Activated > > > > 'autoLink/1' on connection broker1 > > > > > > > > I see the connection established at the broker level, I do not > > see > > > > any sessions on it and thus, cannot publish messages. Actually, > > I > > > > got an amqp:not-found while trying to send messages > > > > (trace) [1]:0 <- @detach(22) [handle=0, closed=true, error=@er > > ror( > > > > 29) [condition=:"amqp:not-found", description="Could not find > > > > destination for source > > > > > > 'Source{address=domain/subdomain/queue1,durable=none,expiryPolicy=l > > > > ink-detach,dynamic=false}'"]] > > > > > > > > The first "/" disappeared (confirmed at qdmanage). > > > > > > > > I also tried the opposite which is to create the qdrouterd > > config > > > > w/o the first "/" (e.g. domain/subdomain...) but then, it looks > > > > like the jms clients need the first "/" (and get stcuk, waiting > > > > for...) > > > > @attach(18) [name="qpid-jms:sender:ID:822e5c62-3157-45b5-878e- > > > > 966d92101315:1:1:1:/domain/subdomain/queue1", handle=0, > > role=false, > > > > snd-settle-mode=0, rcv-settle-mode=0, source=@source(40) > > > > [address="ID:822e5c62-3157-45b5-878e-966d92101315:1:1:1", > > > > durable=0, expiry-policy=:"session-end", timeout=0, > > dynamic=false, > > > > outcomes=@PN_SYMBOL[:"amqp:accepted:list", > > :"amqp:rejected:list", > > > > :"amqp:released:list", :"amqp:modified:list"]], target=@target( > > 41) > > > > [address="/domain/subdomain/queue1", durable=0, expiry- > > > > policy=:"session-end", timeout=0, dynamic=false, capabilities=@ > > PN_S > > > > YMBOL[:queue]], incomplete-unsettled=false, initial-delivery- > > > > count=0, desired-capabilities=@PN_SYMBOL[:"DELAYED_DELIVERY"]] > > > > Wed Apr 5 11:25:20 2017 ROUTER_CORE (trace) Core action > > > > 'link_first_attach' > > > > Wed Apr 5 11:25:20 2017 SERVER (trace) [5]:1 -> @attach(18) > > > > [name="qpid-jms:sender:ID:822e5c62-3157-45b5-878e- > > > > 966d92101315:1:1:1:/domain/subdomain/queue1", handle=0, > > role=true, > > > > snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) > > > > [address="ID:822e5c62-3157-45b5-878e-966d92101315:1:1:1", > > > > durable=0, timeout=0, dynamic=false, outcomes=@PN_SYMBOL[:"amqp > > :acc > > > > epted:list", :"amqp:rejected:list", :"amqp:released:list", > > > > :"amqp:modified:list"]], target=@target(41) > > > > [address="/domain/subdomain/queue1", durable=0, timeout=0, > > > > dynamic=false, capabilities=@PN_SYMBOL[:queue]], initial- > > delivery- > > > > count=0] > > > > > > > > I also tried adding two "/" (e.g. //domain/subdomain) but in > > that > > > > case the "domain" disappear from the destination name (in > > > > qdmanage). > > > > Do I have to use the vhost (the example being using the FQDN)? > > Can > > > > we work on a patch to not remove the first "/" if specified in > > the > > > > configuration? > > > > > > > > Thanks for your help on this. > > > > > > > > Regards. > > > > > > > > > > > > On Fri, Mar 31, 2017 at 3:27 AM, Olivier Mallassi > > <olivier.mallassi > > > > @gmail.com> wrote: > > > > > Hi Ganesh > > > > > > > > > > here it is https://issues.apache.org/jira/browse/DISPATCH-734 > > > > > > > I will try to do more tests. > > > > > > > > > > Thx. > > > > > > > > > > On Thu, Mar 30, 2017 at 4:10 PM, Ganesh Murthy <gmurthy@redha > > t.co > > > > > m> wrote: > > > > > > ----- Original Message ----- > > > > > > > From: "Olivier Mallassi" <[email protected]> > > > > > > > To: [email protected] > > > > > > > Cc: "Alan Conway" <[email protected]> > > > > > > > Sent: Wednesday, March 29, 2017 3:30:48 PM > > > > > > > Subject: Re: Configuring addresses starting with '/' on > > qpid- > > > > > > dispatch router 0.7.0 > > > > > > > > > > > > > > To complement and certainly explain the need, We would > > like > > > > > > urls like > > > > > > > amqp://ip:port/domain/subdomain1/queueA or > > > > > > > amqp://ip:port/domain/subdomain2/queueB > > > > > > > + use routing capabilities to route queueA, queueB on > > > > > > different brokers or > > > > > > > even queueA to brokers and queueB to another dispatch- > > router > > > > > > (e.g. for > > > > > > > external integration) > > > > > > > > > > > > > > I did some really quick and basic tests using the > > dispatch- > > > > > > router. > > > > > > > § qdmanage create --type > > > > > > org.apache.qpid.dispatch.router.config.autoLink > > > > > > > addr=/domain/subdomain/queueA dir=in connection=broker3 > > > > > > > § sending / receiving messaging using the > > simple_recv/send.py > > > > > > scripts. > > > > > > > > > > > > > > It appears that the messages are well published / > > consumed. > > > > > > sounds correct > > > > > > > to you? > > > > > > > > > > > > > > yet (and this is not really important), the qdstat > > displays > > > > > > weird labels > > > > > > > > > > > > > > mobile queue.first 0 0 > > 0 > > > > > > 0 0 > > > > > > > 0 0 0 > > > > > > > > > > > > > > local temp.2ndwYNc5ZaHaD2O 1 > > > > > > > > 0 0 > > > > > > > 0 0 0 0 > > > > > > > > > > > > > > unknown: s ubdomain/queueA 1 > > > > > > > > 0 200 > > > > > > > 200 0 0 0 > > > > > > > > > > > > > > unknown: s ubdomain/queueA 0 > > > > > > > > 0 0 > > > > > > > 0 0 0 0 > > > > > > > > > > > > > > version used: dispatch-router 0.7.0 > > > > > > > > > > > > > The above qdstat output does look weird. Can you please > > enter a > > > > > > JIRA detailing the steps we can use to reproduce this this > > > > > > problem? > > > > > > Thanks. > > > > > > > > > > > > > > On Wed, Mar 29, 2017 at 12:15 PM, Rob Godfrey > > <rob.j.godfrey@ > > > > > > gmail.com> > > > > > > > wrote: > > > > > > > > > > > > > > > On 29 March 2017 at 11:48, Ted Ross <[email protected]> > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 03/08/2017 02:33 PM, Alan Conway wrote: > > > > > > > > > > > > > > > > > >> On Fri, 2017-03-03 at 09:58 +0000, Antoine Chevin > > wrote: > > > > > > > > >> > > > > > > > > >>> Hello, > > > > > > > > >>> > > > > > > > > >>> Do you have an idea on the below behavior? > > > > > > > > >>> > > > > > > > > >> > > > > > > > > >> This is related to early drafts of the AMQP > > addressing > > > > > > specification, > > > > > > > > >> but those are out of date now and the specification > > is > > > > > > still not > > > > > > > > >> released. > > > > > > > > >> > > > > > > > > >> Given that, I think this behavior is probably not > > > > > > helpful - dispatch > > > > > > > > >> should accept address exactly as provided by the > > user > > > > > > and do no > > > > > > > > >> modification. I'm not 100% sure if that would cause > > any > > > > > > internal > > > > > > > > >> problems for the router, if not we should raise an > > > > > > issue. > > > > > > > > >> > > > > > > > > >> Ted do you have any thoughts? > > > > > > > > >> > > > > > > > > > > > > > > > > > > Dispatch normalizes addresses to make sure that > > various > > > > > > "equivalent" > > > > > > > > forms > > > > > > > > > are hashed to the same entry in the address table. > > > > > > > > > > > > > > > > > > As Alan pointed out, we use a URL-like address format > > per > > > > > > early drafts of > > > > > > > > > the addressing specification. As such, the leading > > slash > > > > > > is removed from > > > > > > > > > the normalized address. > > > > > > > > > > > > > > > > > > > > > > > > > > What are the normalization rules, and why is dispatch > > > > > > assuming that > > > > > > > > removing a leading slash is correct (since in this case > > it > > > > > > is not - the > > > > > > > > Java Broker does its own normalization - and if you > > want > > > > > > you can query it > > > > > > > > and find out what prefixes it considers equivalent)? > > > > > > > > > > > > > > > > -- Rob > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > >>> Thank you, > > > > > > > > >>> Regards, > > > > > > > > >>> Antoine > > > > > > > > >>> > > > > > > > > >>> -----Original Message----- > > > > > > > > >>> From: Antoine Chevin [mailto:[email protected] > > om] > > > > > > > > >>> Sent: jeudi 2 mars 2017 10:43 > > > > > > > > >>> To: [email protected] > > > > > > > > >>> Subject: Configuring addresses starting with '/' on > > > > > > qpid-dispatch > > > > > > > > >>> router > > > > > > > > >>> 0.7.0 > > > > > > > > >>> > > > > > > > > >>> Hello, > > > > > > > > >>> > > > > > > > > >>> I tried to configure addresses starting with a '/' > > but > > > > > > using qdstat I > > > > > > > > >>> see > > > > > > > > >>> that this '/' is removed. Is it expected? > > > > > > > > >>> I noticed the same behavior with autolinks. > > > > > > > > >>> > > > > > > > > >>> Thank you, > > > > > > > > >>> Regards, > > > > > > > > >>> Antoine > > > > > > > > >>> > > > > > > > > >> > > > > > > > > >> > > > > > > > > > --------------------------------------------------- > > ---- > > > > > > -------------- > > > > > > > > > To unsubscribe, e-mail: [email protected] > > .org > > > > > > > > > For additional commands, e-mail: [email protected] > > he.o > > > > > > rg > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------- > > ---- > > > > > > -------- > > > > > > To unsubscribe, e-mail: [email protected] > > > > > > For additional commands, e-mail: [email protected] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
