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 <
[email protected]> 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 <[email protected]> wrote:
>
>>
>>
>> ----- Original Message -----
>> > From: "Olivier Mallassi" <[email protected]>
>> > To: [email protected]
>> > Cc: "Alan Conway" <[email protected]>
>> > Sent: Wednesday, March 29, 2017 3:30:48 PM
>> > Subject: Re: Configuring addresses starting with '/' on qpid-dispatch
>> router 0.7.0
>> >
>> > To complement and certainly explain the need, We would like urls like
>> > amqp://ip:port/domain/subdomain1/queueA or
>> > amqp://ip:port/domain/subdomain2/queueB
>> > + use routing capabilities to route queueA, queueB on different
>> brokers or
>> > even queueA to brokers and queueB to another dispatch-router (e.g. for
>> > external integration)
>> >
>> > I did some really quick and basic tests using the dispatch-router.
>> > § qdmanage create --type org.apache.qpid.dispatch.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 <[email protected]>
>> > wrote:
>> >
>> > > On 29 March 2017 at 11:48, Ted Ross <[email protected]> wrote:
>> > >
>> > > >
>> > > >
>> > > > On 03/08/2017 02:33 PM, Alan Conway wrote:
>> > > >
>> > > >> On Fri, 2017-03-03 at 09:58 +0000, Antoine Chevin wrote:
>> > > >>
>> > > >>> Hello,
>> > > >>>
>> > > >>> Do you have an idea on the below behavior?
>> > > >>>
>> > > >>
>> > > >> This is related to early drafts of the AMQP addressing
>> specification,
>> > > >> but those are out of date now and the specification is still not
>> > > >> released.
>> > > >>
>> > > >> Given that, I think this behavior is probably not helpful -
>> dispatch
>> > > >> should accept address exactly as provided by the user and do no
>> > > >> modification. I'm not 100% sure if that would cause any internal
>> > > >> problems for the router, if not we should raise an issue.
>> > > >>
>> > > >> Ted do you have any thoughts?
>> > > >>
>> > > >
>> > > > Dispatch normalizes addresses to make sure that various "equivalent"
>> > > forms
>> > > > are hashed to the same entry in the address table.
>> > > >
>> > > > As Alan pointed out, we use a URL-like address format per early
>> drafts of
>> > > > the addressing specification. As such, the leading slash is
>> removed from
>> > > > the normalized address.
>> > > >
>> > > >
>> > > What are the normalization rules, and why is dispatch assuming that
>> > > removing a leading slash is correct (since in this case it is not -
>> the
>> > > Java Broker does its own normalization - and if you want you can
>> query it
>> > > and find out what prefixes it considers equivalent)?
>> > >
>> > > -- Rob
>> > >
>> > >
>> > > >
>> > > >
>> > > >>
>> > > >>> Thank you,
>> > > >>> Regards,
>> > > >>> Antoine
>> > > >>>
>> > > >>> -----Original Message-----
>> > > >>> From: Antoine Chevin [mailto:[email protected]]
>> > > >>> Sent: jeudi 2 mars 2017 10:43
>> > > >>> To: [email protected]
>> > > >>> Subject: Configuring addresses starting with '/' on qpid-dispatch
>> > > >>> router
>> > > >>> 0.7.0
>> > > >>>
>> > > >>> Hello,
>> > > >>>
>> > > >>> I tried to configure addresses starting with a '/' but using
>> qdstat I
>> > > >>> see
>> > > >>> that this '/' is removed. Is it expected?
>> > > >>> I noticed the same behavior with autolinks.
>> > > >>>
>> > > >>> Thank you,
>> > > >>> Regards,
>> > > >>> Antoine
>> > > >>>
>> > > >>
>> > > >>
>> > > > ------------------------------------------------------------
>> ---------
>> > > > To unsubscribe, e-mail: [email protected]
>> > > > For additional commands, e-mail: [email protected]
>> > > >
>> > > >
>> > >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>>
>
