----- Original Message -----
> On Tue, 2015-01-27 at 09:44 -0500, Michael Goulish wrote:
> > I use this field in my 'topologist' gadget that reads topology
> > information from a network of qdrouters.
> > 
> > I only have a connection to router A, but I am able to make topo
> > requests of the other routers (after I learn their names) by setting
> > the x-amqp-to field to a value like  "amqp:/_topo/0/QDR.B" .
> > 
> > This causes my local router to forward the request to router B
> > (to which I have no connection), B consumes the request,
> > and I get the answer back.
> 
> Far as I can tell this is strictly a qpid::messenger client thing. It
> won't work with proton.Messenger or the proton engine directly. I
> thought you were using the proton engine directly so I am confused.
> 
> Are you also putting the address in the normal AMQP to: field? If so the
> x-amqp-to is probably an unnecessary distraction. If not, I don't know
> what I am talking about (would be curious to find out...)



I was using the engine directly for some clients for speed testing.

This qpid::messaging code I am using is in my 'topologist' program that 
talks to (and then abuses) router networks.

I tried just now changing my code to just put that addr in "amqp-to",
and just "to", instead of "x-amqp-to".   It hanged.   

But perhaps the routers are just expecting it that way?

Here is snippet, getting ready to ask a router node for its name:


  Message request;
  request.setReplyTo(response_addr);
  request.setProperty("x-amqp-to", "amqp:/_local/$management");
  request.setProperty("operation", "QUERY");
  request.setProperty("entityType", "org.apache.qpid.dispatch.router");
  request.setProperty("type", "org.amqp.management" );
  request.setProperty("name", "self");




> 
> > 
> > 
> > 
> > ----- Original Message -----
> > > On 01/23/2015 01:53 PM, Alan Conway wrote:
> > > > I'm trying to determine if the message header x-amqp-to has any use or
> > > > if it's a historical leftover. Here's what I found in the 3 qpid
> > > > projects:
> > > >
> > > > == proton
> > > > == dispatch
> > > > doc/book/release-0.1.md:        request.setProperty("x-amqp-to",
> > > > "amqp:/_local/$management");
> > > > doc/book/using.md:        request.setProperty("x-amqp-to",
> > > > "amqp:/_local/$management");
> > > > == qpid
> > > > qpid/cpp/AMQP_1.0:for the header section, and x-amqp-to,
> > > > x-amqp-absolute-expiry-time,
> > > > qpid/cpp/src/qpid/messaging/amqp/EncodedMessage.cpp:
> > > > map["x-amqp-to"] = to.str();
> > > > qpid/cpp/src/qpid/messaging/amqp/SenderContext.cpp:const std::string
> > > > X_AMQP_TO("x-amqp-to");
> > > >
> > > > I believe the dispatch documentation references are incorrect and
> > > > should
> > > > be setting the normal "to" address for the message, not the x-amqp-to
> > > > property. I'll test that and correct if its the case.
> > > >
> > > > I followed the bread crumbs in the qpid code base and all I could find
> > > > was (a lot of) code for propagating this property along the message
> > > > encoding and transformation path and making it available in the Message
> > > > API. I couldn't find any code that actually *uses* it.
> > > >
> > > > Does anyone know if I'm missing something or can we get rid of it
> > > > entirely?
> > > 
> > > The qpid::messaging::Message class has no 'to' field. However the AMQP
> > > 1.0 specification does have such a field in the properties section. The
> > > 'x-amqp-to' label is a special key allowing the AMQP 1.0 field to be
> > > accessed (for both incoming and outgoing messages) as a special property
> > > (via Message::getProperty()/setProperty()).
> > > 
> > > It should not be needed outside the qpid::messaging client (but within
> > > that it is still needed).
> > > 
> > > 
> > > ---------------------------------------------------------------------
> > > 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]
> > 
> 
> 
> 
> ---------------------------------------------------------------------
> 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]

Reply via email to