hum. I guess you got the point. At least, you may have helped me better
understanding.
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)
Attach{name='qpid-jms:sender:ID:c6c88db6-7305-42ee-a3f4-fd83fb5a9981:1:1:1:/domain/subdomain/queue1',
handle=0, role=SENDER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST,
source=Source{address='ID:c6c88db6-7305-42ee-a3f4-fd83fb5a9981:1:1:1',
durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
dynamicNodeProperties=null, distributionMode=null, filter=null,
defaultOutcome=null, outcomes=[amqp:accepted:list, amqp:rejected:list,
amqp:released:list, amqp:modified:list], capabilities=null}, target=
*Target{address='/domain/subdomain/queue1'*, durable=NONE,
expiryPolicy=SESSION_END, timeout=0, dynamic=false,
dynamicNodeProperties=null, capabilities=[queue]}, unsettled=null,
incompleteUnsettled=false, initialDeliveryCount=0, maxMessageSize=null,
offeredCapabilities=null, desiredCapabilities=[DELAYED_DELIVERY],
properties=null}
Then, I assume (from my understanding of previous Rob's emails) the broker
use the Target, get the first "/", find the virtual host etc...
>From python, the "//" is needed.
python ./simpleSend.py -a localhost:5672*//domain*/subdomain/queue1
@attach(18)
[name="60e41d4e-f2cc-4238-a603-46b0cc697859-/domain/subdomain/queue1",
handle=0, role=false, snd-settle-mode=2, rcv-settle-mode=0,
source=@source(40) [durable=0, timeout=0, dynamic=false], target=*@target(41)
[address="/domain*/subdomain/queue1",
python ./simpleSend.py -a localhost:5672*/domain*/subdomain/queue1
@attach(18)
[name="69440e09-5f3c-4cb8-988f-410631a1d960-domain/subdomain/queue1",
handle=0, role=false, snd-settle-mode=2, rcv-settle-mode=0,
source=@source(40) [durable=0, timeout=0, dynamic=false], target=*@target(41)
[address="domain*/subdomain/queue1"
*Then, by using the Dispatch Router*
The dispatch router has been configured with address and autoLink to
*/domain*/subdomain/queue1. The AMQP Adress is normalized, hence removing
the first "/"
Looking at the dispatch router trace:
@attach(18) [name="qdlink.obj_741zOpVkhxg", handle=0, role=true,
snd-settle-mode=2, rcv-settle-mode=0, source=@source(40)
*[address="domain/subdomain/queue1*", durable=0,
expiry-policy=:"link-detach", timeout=0, dynamic=false], target=@target(41)
[durable=0, timeout=0, dynamic=false], initial-delivery-count=0]
Thu Apr 6 23:05:01 2017 SERVER (trace) [1]:RAW:
"\x00\x00\x00\x89\x02\x00\x00\x00\x00S\x12\xd0\x00\x00\x00y\x00\x00\x00\x0a\xa1\x16qdlink.obj_741zOpVkhxgR\x00AP\x02P\x00\x00S(\xd0\x00\x00\x005\x00\x00\x00\x0b\xa1\x17domain/subdomain/queue1R\x00\xa3\x0blink-detachR\x00B@
@@@@@\x00S)\xd0\x00\x00\x00\x0d\x00\x00\x00\x07@R\x00@R\x00B@@@@R\x00"
Thu Apr 6 23:05:01 2017 SERVER (trace) [1]:1 -> @attach(18)
[name="qdlink.dhMP1_rDNeqVT6M", handle=0, role=false, snd-settle-mode=2,
rcv-settle-mode=0, source=@source(40) [durable=0, timeout=0,
dynamic=false], target=@target(41) *[address="domain/subdomain/queue1*",
durable=0, expiry-policy=:"link-detach", timeout=0, dynamic=false],
initial-delivery-count=0]
Thu Apr 6 23:05:01 2017 SERVER (trace) [1]:RAW:
"\x00\x00\x00\x89\x02\x00\x00\x01\x00S\x12\xd0\x00\x00\x00y\x00\x00\x00\x0a\xa1\x16qdlink.dhMP1_rDNeqVT6MR\x00BP\x02P\x00\x00S(\xd0\x00\x00\x00\x11\x00\x00\x00\x0b@R
\x00@R\x00B@
@@@@@\x00S)\xd0\x00\x00\x001\x00\x00\x00\x07\xa1\x17domain/subdomain/queue1R\x00\xa3\x0blink-detachR\x00B@
@@@R\x00"
The AMQP adress being normalized, the link to the broker cannot be created
(cf previous test)
Nos the dispatch router is configured with address and autoLink to
*//domain*/subdomain/queue1 (double "/")
my expectation would have been that only the first "/" would be removed (as
in the python test above) but looking at the trace:
@attach(18) [name="qdlink.FsOYhn7KWFg6pBe", handle=0, role=true,
snd-settle-mode=2, rcv-settle-mode=0, source=@source(40)
[address="subdomain/queue1", durable=0, expiry-policy=:"link-detach",
timeout=0, dynamic=false], target=@target(41) [durable=0, timeout=0,
dynamic=false], initial-delivery-count=0]
Thu Apr 6 23:06:50 2017 SERVER (trace) [1]:RAW:
"\x00\x00\x00\x82\x02\x00\x00\x00\x00S\x12\xd0\x00\x00\x00r\x00\x00\x00\x0a\xa1\x16qdlink.FsOYhn7KWFg6pBeR\x00AP\x02P\x00\x00S(\xd0\x00\x00\x00.\x00\x00\x00\x0b\xa1\x10subdomain/queue1R\x00\xa3\x0blink-detachR\x00B@
@@@@@\x00S)\xd0\x00\x00\x00\x0d\x00\x00\x00\x07@R\x00@R\x00B@@@@R\x00"
Thu Apr 6 23:06:50 2017 SERVER (trace) [1]:1 -> @attach(18)
[name="qdlink.T9PtHsTOXy+7FHV", handle=0, role=false, snd-settle-mode=2,
rcv-settle-mode=0, source=@source(40) [durable=0, timeout=0,
dynamic=false], target=@target(41) [*address="subdomain/queue1*",
durable=0, expiry-policy=:"link-detach", timeout=0, dynamic=false],
initial-delivery-count=0]
Thu Apr 6 23:06:50 2017 SERVER (trace) [1]:RAW:
"\x00\x00\x00\x82\x02\x00\x00\x01\x00S\x12\xd0\x00\x00\x00r\x00\x00\x00\x0a\xa1\x16qd
the //domain is removed.
in both cases, the Link between the dispatch router & the broker cannot be
established (just after I see a @detach frame)
Is my understanding correct?
Is the removal of //domain the expected behavior? could we imagine having
something similar to the python example above? hence, the address
normalization would not be the same between qpid-dispatch-router &
qpid-java-broker but at least, it could work.
Thx.
olivier.
On Thu, Apr 6, 2017 at 9:03 PM, Alan Conway <acon...@redhat.com> 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@gmail
> > .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=@error(
> > > 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 <gmur...@redhat.co
> > > > m> wrote:
> > > > > ----- Original Message -----
> > > > > > From: "Olivier Mallassi" <olivier.malla...@gmail.com>
> > > > > > To: users@qpid.apache.org
> > > > > > Cc: "Alan Conway" <acon...@redhat.com>
> > > > > > 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 <tr...@redhat.com>
> > > > > 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:antoine.che...@gmail.com]
> > > > > > > >>> Sent: jeudi 2 mars 2017 10:43
> > > > > > > >>> To: users@qpid.apache.org
> > > > > > > >>> 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: users-unsubscr...@qpid.apache.org
> > > > > > > > For additional commands, e-mail: users-help@qpid.apache.o
> > > > > rg
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > > -------------------------------------------------------------
> > > > > --------
> > > > > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> > > > > For additional commands, e-mail: users-h...@qpid.apache.org
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
>
>
>
