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.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 <[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] > >
