You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by Olivier Mallassi <ol...@gmail.com> on 2017/04/05 09:48:30 UTC
Re: Configuring addresses starting with '/' on qpid-dispatch router 0.7.0
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/queue*1,
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=link-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_SYMBOL[: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:accepted: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 <gm...@redhat.com> wrote:
>
>>
>>
>> ----- Original Message -----
>> > From: "Olivier Mallassi" <ol...@gmail.com>
>> > To: users@qpid.apache.org
>> > Cc: "Alan Conway" <ac...@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.route
>> r.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 <ro...@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.chevin@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-unsubscribe@qpid.apache.org
>> > > > For additional commands, e-mail: users-help@qpid.apache.org
>> > > >
>> > > >
>> > >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: users-help@qpid.apache.org
>>
>>
>
Re: Configuring addresses starting with '/' on qpid-dispatch router 0.7.0
Posted by Olivier Mallassi <ol...@gmail.com>.
Well, sorry I had to focus on something else.
Thx for the hep Ganesh but it does not look to work.
a. if I use /// in the auto-link/adress config, the link is not done with
the broker. I see attach frame with an address w/o the slashes and then
some end frames . it does not work (the broker expect to have the first
slash)
b. If I use //// in the auto-link config, the link to the broker is done
(attach frame w/o the end frame)
using qdstats I see the destinations with the first /
so then I try python simpleSend localhost://domain/... -> here it creates a
third destination on the dispatch (qdstat) , dir=in and the client stays
stuck (as if it was waiting for a consumer)
I will try do get more focus on this. but yes, that would be great if we
could simplify this "slashes" issue :) and have a complete case working.
many thx for your support.
oliver.
On Mon, Apr 10, 2017 at 5:36 PM, Ganesh Murthy <gm...@redhat.com> wrote:
>
>
> ----- Original Message -----
> > From: "Olivier Mallassi" <ol...@gmail.com>
> > To: "Alan Conway" <ac...@redhat.com>
> > Cc: "Rob Godfrey" <ro...@gmail.com>, gmurthy@redhat.com,
> users@qpid.apache.org
> > Sent: Saturday, April 8, 2017 8:04:17 AM
> > Subject: Re: Configuring addresses starting with '/' on qpid-dispatch
> router 0.7.0
> >
> > So following your idea, I am now trying to connect client.
> >
> > python simpleSend.py -a amqp://localhost:20202//domain/subdomain/queue1
> -m
> > 10000 (note the //)
> > on the client, I see the attach frame
> >
> > @attach(18)
> > [name="71e559bd-81f1-4512-9223-d226aa813bb7-/domain/subdomain/queue1",
> > handle=0, role=true, 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,
> > timeout=0, dynamic=false], initial-delivery-count=0, max-message-size=0]
> >
> >
> > yet, usind qdstat
> >
> > qdstat -b localhost:20202 -a
> > Router Addresses
> > class addr phs distrib in-proc local remote
> > cntnr in out thru to-proc from-proc
> >
> > ============================================================
> =======================================================
> > local $_management_internal closest 1 0 0
> > 0 0 0 0 0 0
> > mobile $management 0 closest 1 0 0
> > 0 2 0 0 2 0
> > local $management closest 1 0 0
> > 0 0 0 0 0 0
> > mobile */domain*/subdomain/queue1 1 balanced 0 0 0
> > 0 0 0 0 0 0
> > mobile */domain*/subdomain/queue1 0 balanced 0 1 0
> > 0 0 0 0 0 0
> > mobile *domain/*subdomain/queue1 0 balanced 0 0 0
> > 0 0 0 0 0 0
> > local temp.k1lchlMcGRfNM3N balanced 0 1 0
> > 0 0 0 0 0 0
> >
> >
> > note the /domain are created via autoLink (following the Alan's idea of
> > ////)
> >
> > the third one (domain/subdomain w/o the first /) is created (and deleted)
> > when starting the python client (and stopping it).
> >
> > Looks like the dispatch router is also normalizing incoming Adress
> > (independently of the number of /// by the way ;) )
> The router does normalize incoming addresses. Here is the code that does
> that -
>
> https://github.com/apache/qpid-dispatch/blob/master/src/
> router_core/connections.c#L1061
>
> From what I can see, the router remives a maximum of 3 leading slashes.
>
> So, if you run a simple_send on the router like this -
>
> python simple_recv.py -m1 --address localhost////examples, the router
> stores /examples in its address table.
>
> If you have the following auto link in your config file, the address pulp
> gets address table -
>
> autoLink {
> addr: ///pulp
> connection: broker
> dir: in
> }
>
> We will have to come up with a comprehensive solution to the problem of
> leading slashes.
>
> >
> > On Fri, Apr 7, 2017 at 10:48 PM, Olivier Mallassi <
> > olivier.mallassi@gmail.com> wrote:
> >
> > > Crafty :)
> > >
> > > I have just ran quick tests and it helps establishing the link between
> the
> > > dispatch & broker (attach flow frames)
> > > I am yet not able to send messages (got the attach frame by the client
> get
> > > stuck) I have to digg into
> > >
> > > Do you want me to create a Jira on this?
> > >
> > > Thx
> > >
> > >
> > >
> > > On Fri, 7 Apr 2017 at 17:38, Alan Conway <ac...@redhat.com> wrote:
> > >
> > >> On Fri, 2017-04-07 at 17:08 +0200, Olivier Mallassi wrote:
> > >> >
> > >> > I am fine with the "//" as long as it is not considered as
> connection
> > >> > information :)
> > >> >
> > >>
> > >> Random thought: have you tried "////addr" in the configuration file?
> > >>
> > >> "//" + "" + "/" + "/addr" == "/addr"
> > >>
> > >> I haven't tried it, I may be dreaming. It is definitely not the
> > >> solution, but maybe a useful temporary workaround.
> > >>
> > >> > > 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!!
> > >> >
> > >>
> > >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
Re: Configuring addresses starting with '/' on qpid-dispatch router
0.7.0
Posted by Ganesh Murthy <gm...@redhat.com>.
----- Original Message -----
> From: "Olivier Mallassi" <ol...@gmail.com>
> To: "Alan Conway" <ac...@redhat.com>
> Cc: "Rob Godfrey" <ro...@gmail.com>, gmurthy@redhat.com, users@qpid.apache.org
> Sent: Saturday, April 8, 2017 8:04:17 AM
> Subject: Re: Configuring addresses starting with '/' on qpid-dispatch router 0.7.0
>
> So following your idea, I am now trying to connect client.
>
> python simpleSend.py -a amqp://localhost:20202//domain/subdomain/queue1 -m
> 10000 (note the //)
> on the client, I see the attach frame
>
> @attach(18)
> [name="71e559bd-81f1-4512-9223-d226aa813bb7-/domain/subdomain/queue1",
> handle=0, role=true, 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,
> timeout=0, dynamic=false], initial-delivery-count=0, max-message-size=0]
>
>
> yet, usind qdstat
>
> qdstat -b localhost:20202 -a
> Router Addresses
> class addr phs distrib in-proc local remote
> cntnr in out thru to-proc from-proc
>
> ===================================================================================================================
> local $_management_internal closest 1 0 0
> 0 0 0 0 0 0
> mobile $management 0 closest 1 0 0
> 0 2 0 0 2 0
> local $management closest 1 0 0
> 0 0 0 0 0 0
> mobile */domain*/subdomain/queue1 1 balanced 0 0 0
> 0 0 0 0 0 0
> mobile */domain*/subdomain/queue1 0 balanced 0 1 0
> 0 0 0 0 0 0
> mobile *domain/*subdomain/queue1 0 balanced 0 0 0
> 0 0 0 0 0 0
> local temp.k1lchlMcGRfNM3N balanced 0 1 0
> 0 0 0 0 0 0
>
>
> note the /domain are created via autoLink (following the Alan's idea of
> ////)
>
> the third one (domain/subdomain w/o the first /) is created (and deleted)
> when starting the python client (and stopping it).
>
> Looks like the dispatch router is also normalizing incoming Adress
> (independently of the number of /// by the way ;) )
The router does normalize incoming addresses. Here is the code that does that -
https://github.com/apache/qpid-dispatch/blob/master/src/router_core/connections.c#L1061
From what I can see, the router remives a maximum of 3 leading slashes.
So, if you run a simple_send on the router like this -
python simple_recv.py -m1 --address localhost////examples, the router stores /examples in its address table.
If you have the following auto link in your config file, the address pulp gets address table -
autoLink {
addr: ///pulp
connection: broker
dir: in
}
We will have to come up with a comprehensive solution to the problem of leading slashes.
>
> On Fri, Apr 7, 2017 at 10:48 PM, Olivier Mallassi <
> olivier.mallassi@gmail.com> wrote:
>
> > Crafty :)
> >
> > I have just ran quick tests and it helps establishing the link between the
> > dispatch & broker (attach flow frames)
> > I am yet not able to send messages (got the attach frame by the client get
> > stuck) I have to digg into
> >
> > Do you want me to create a Jira on this?
> >
> > Thx
> >
> >
> >
> > On Fri, 7 Apr 2017 at 17:38, Alan Conway <ac...@redhat.com> wrote:
> >
> >> On Fri, 2017-04-07 at 17:08 +0200, Olivier Mallassi wrote:
> >> >
> >> > I am fine with the "//" as long as it is not considered as connection
> >> > information :)
> >> >
> >>
> >> Random thought: have you tried "////addr" in the configuration file?
> >>
> >> "//" + "" + "/" + "/addr" == "/addr"
> >>
> >> I haven't tried it, I may be dreaming. It is definitely not the
> >> solution, but maybe a useful temporary workaround.
> >>
> >> > > 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!!
> >> >
> >>
> >>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Configuring addresses starting with '/' on qpid-dispatch router
0.7.0
Posted by Alan Conway <ac...@redhat.com>.
On Thu, 2017-04-06 at 23:38 +0200, Olivier Mallassi wrote:
> hum. I guess you got the point. At least, you may have helped me
> better
> understanding.
Wireshark might be a useful tool for you - it monitors network traffic
and gives a good readable display for AMQP packets. That will tell you
exactly what the AMQP address is in the packets that arrive at
dispatch: after any client-side parsing and before any possible
dispatch modification. That should pin down who is messing with your
addresses.
> 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=*@ta
> rget(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=*@ta
> rget(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=@targ
> et(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\x
> 00\x0a\xa1\x16qdlink.obj_741zOpVkhxgR\x00AP\x02P\x00\x00S(\xd0\x00\x0
> 0\x005\x00\x00\x00\x0b\xa1\x17domain/subdomain/queue1R\x00\xa3\x0blin
> k-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\x
> 00\x0a\xa1\x16qdlink.dhMP1_rDNeqVT6MR\x00BP\x02P\x00\x00S(\xd0\x00\x0
> 0\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\x
> 00\x0a\xa1\x16qdlink.FsOYhn7KWFg6pBeR\x00AP\x02P\x00\x00S(\xd0\x00\x0
> 0\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\x
> 00\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 <ac...@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@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'
> > > > \u2026
> > > > 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,expiryPoli
> > > > cy=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" <ol...@gmail.com>
> > > > > > > To: users@qpid.apache.org
> > > > > > > Cc: "Alan Conway" <ac...@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.chevin@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-unsubscribe@qpid.apache
> > > > > > > > > .org
> > > > > > > > > For additional commands, e-mail: users-help@qpid.apac
> > > > > > > > > he.o
> > > > > >
> > > > > > rg
> > > > > > > > >
> > > > > > > > >
> > > > > >
> > > > > > ---------------------------------------------------------
> > > > > > ----
> > > > > > --------
> > > > > > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> > > > > > For additional commands, e-mail: users-help@qpid.apache.org
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> >
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Configuring addresses starting with '/' on qpid-dispatch router 0.7.0
Posted by Olivier Mallassi <ol...@gmail.com>.
So following your idea, I am now trying to connect client.
python simpleSend.py -a amqp://localhost:20202//domain/subdomain/queue1 -m
10000 (note the //)
on the client, I see the attach frame
@attach(18)
[name="71e559bd-81f1-4512-9223-d226aa813bb7-/domain/subdomain/queue1",
handle=0, role=true, 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,
timeout=0, dynamic=false], initial-delivery-count=0, max-message-size=0]
yet, usind qdstat
qdstat -b localhost:20202 -a
Router Addresses
class addr phs distrib in-proc local remote
cntnr in out thru to-proc from-proc
===================================================================================================================
local $_management_internal closest 1 0 0
0 0 0 0 0 0
mobile $management 0 closest 1 0 0
0 2 0 0 2 0
local $management closest 1 0 0
0 0 0 0 0 0
mobile */domain*/subdomain/queue1 1 balanced 0 0 0
0 0 0 0 0 0
mobile */domain*/subdomain/queue1 0 balanced 0 1 0
0 0 0 0 0 0
mobile *domain/*subdomain/queue1 0 balanced 0 0 0
0 0 0 0 0 0
local temp.k1lchlMcGRfNM3N balanced 0 1 0
0 0 0 0 0 0
note the /domain are created via autoLink (following the Alan's idea of
////)
the third one (domain/subdomain w/o the first /) is created (and deleted)
when starting the python client (and stopping it).
Looks like the dispatch router is also normalizing incoming Adress
(independently of the number of /// by the way ;) )
On Fri, Apr 7, 2017 at 10:48 PM, Olivier Mallassi <
olivier.mallassi@gmail.com> wrote:
> Crafty :)
>
> I have just ran quick tests and it helps establishing the link between the
> dispatch & broker (attach flow frames)
> I am yet not able to send messages (got the attach frame by the client get
> stuck) I have to digg into
>
> Do you want me to create a Jira on this?
>
> Thx
>
>
>
> On Fri, 7 Apr 2017 at 17:38, Alan Conway <ac...@redhat.com> wrote:
>
>> On Fri, 2017-04-07 at 17:08 +0200, Olivier Mallassi wrote:
>> >
>> > I am fine with the "//" as long as it is not considered as connection
>> > information :)
>> >
>>
>> Random thought: have you tried "////addr" in the configuration file?
>>
>> "//" + "" + "/" + "/addr" == "/addr"
>>
>> I haven't tried it, I may be dreaming. It is definitely not the
>> solution, but maybe a useful temporary workaround.
>>
>> > > 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!!
>> >
>>
>>
Re: Configuring addresses starting with '/' on qpid-dispatch router 0.7.0
Posted by Olivier Mallassi <ol...@gmail.com>.
Crafty :)
I have just ran quick tests and it helps establishing the link between the
dispatch & broker (attach flow frames)
I am yet not able to send messages (got the attach frame by the client get
stuck) I have to digg into
Do you want me to create a Jira on this?
Thx
On Fri, 7 Apr 2017 at 17:38, Alan Conway <ac...@redhat.com> wrote:
> On Fri, 2017-04-07 at 17:08 +0200, Olivier Mallassi wrote:
> >
> > I am fine with the "//" as long as it is not considered as connection
> > information :)
> >
>
> Random thought: have you tried "////addr" in the configuration file?
>
> "//" + "" + "/" + "/addr" == "/addr"
>
> I haven't tried it, I may be dreaming. It is definitely not the
> solution, but maybe a useful temporary workaround.
>
> > > 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!!
> >
>
>
Re: Configuring addresses starting with '/' on qpid-dispatch router
0.7.0
Posted by Alan Conway <ac...@redhat.com>.
On Fri, 2017-04-07 at 17:08 +0200, Olivier Mallassi wrote:
>
> I am fine with the "//" as long as it is not considered as connection
> information :) �
>
Random thought: have you tried "////addr" in the configuration file?
"//" + "" + "/" + "/addr" == "/addr"
I haven't tried it, I may be dreaming. It is definitely not the
solution, but maybe a useful temporary workaround.
> > 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!!�
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Configuring addresses starting with '/' on qpid-dispatch router 0.7.0
Posted by Olivier Mallassi <ol...@gmail.com>.
I hope the colored text will work.
cf. below
On Fri, Apr 7, 2017 at 4:40 PM, Alan Conway <ac...@redhat.com> 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!!
Re: Configuring addresses starting with '/' on qpid-dispatch router
0.7.0
Posted by Alan Conway <ac...@redhat.com>.
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 <ac...@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@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'
> > > > \u2026
> > > > 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" <ol...@gmail.com>
> > > > > > > To: users@qpid.apache.org
> > > > > > > Cc: "Alan Conway" <ac...@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.chevin@gmail.c
> > om]
> > > > > > > > >>> 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-unsubscribe@qpid.apache
> > .org
> > > > > > > > > For additional commands, e-mail: users-help@qpid.apac
> > he.o
> > > > > > rg
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > > ---------------------------------------------------------
> > ----
> > > > > > --------
> > > > > > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> > > > > > For additional commands, e-mail: users-help@qpid.apache.org
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> >
> >
> >
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Configuring addresses starting with '/' on qpid-dispatch router 0.7.0
Posted by Olivier Mallassi <ol...@gmail.com>.
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 <ac...@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 <gmurthy@redhat.co
> > > > m> wrote:
> > > > > ----- Original Message -----
> > > > > > From: "Olivier Mallassi" <ol...@gmail.com>
> > > > > > To: users@qpid.apache.org
> > > > > > Cc: "Alan Conway" <ac...@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.chevin@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-unsubscribe@qpid.apache.org
> > > > > > > > For additional commands, e-mail: users-help@qpid.apache.o
> > > > > rg
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > > -------------------------------------------------------------
> > > > > --------
> > > > > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> > > > > For additional commands, e-mail: users-help@qpid.apache.org
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
>
>
>
Re: Configuring addresses starting with '/' on qpid-dispatch router
0.7.0
Posted by Alan Conway <ac...@redhat.com>.
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'
> > \u2026
> > 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 <gmurthy@redhat.co
> > > m> wrote:
> > > > ----- Original Message -----
> > > > > From: "Olivier Mallassi" <ol...@gmail.com>
> > > > > To: users@qpid.apache.org
> > > > > Cc: "Alan Conway" <ac...@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.chevin@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-unsubscribe@qpid.apache.org
> > > > > > > For additional commands, e-mail: users-help@qpid.apache.o
> > > > rg
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > > -------------------------------------------------------------
> > > > --------
> > > > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> > > > For additional commands, e-mail: users-help@qpid.apache.org
> > > >
> > > >
> > >
> > >
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Configuring addresses starting with '/' on qpid-dispatch router 0.7.0
Posted by Olivier Mallassi <ol...@gmail.com>.
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
Thx
On Wed, 5 Apr 2017 at 11:48, Olivier Mallassi <ol...@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/queue*1,
> 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=link-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_SYMBOL[: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:accepted: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 <gm...@redhat.com> wrote:
>
>
>
> ----- Original Message -----
> > From: "Olivier Mallassi" <ol...@gmail.com>
> > To: users@qpid.apache.org
> > Cc: "Alan Conway" <ac...@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 <ro...@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.chevin@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-unsubscribe@qpid.apache.org
> > > > For additional commands, e-mail: users-help@qpid.apache.org
> > > >
> > > >
> > >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
>
>