I hope the colored text will work. cf. below
On Fri, Apr 7, 2017 at 4:40 PM, Alan Conway <[email protected]> wrote: > 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. > Indeed. there is no client connected here. Yet, I tried this because of the python example above. > > > 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. > This is also my guess. I tried looking at the code. When the link is activated (route_control.c#161) in the method qdr_auto_link_activate_CT, the following line is executed (L 182) qdr_terminus_set_address(term, &key[2]);. In that case, the key[2] contains M1subdomain/queue1. I was trying to find where the "//domain" was removed. it may be in the agent_config_auto_link.c#370 where the addr is parsed. > 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 am fine with the "//" as long as it is not considered as connection information :) > I think Ganesh is already working on that so I'll stop confusing the > issue. > > > Let us know if this is the case, that would be great!!
