The assumption there is that senders are expensive to create?
Yes. Are they? (I always specify the node type, so hopefully no need for
a broker roundtrip)
No, I don't think they are. Especially as you are specifying the node
type to avoid having to look that up. It will do a synchronous,
passive queue declare at present. The reason for that is simply to
ensure the address is valid before you start sending. I could imagine
having some way to disable that or make it async if it proves a problem.
Let's say I'm writing a service processing requests coming from
different clients, each request having a different reply-to address. To
be able to send the responses, do I have to create a new Sender for each
request? If creating a Sender means a sync roundtrip to broker, won't
this kill my performance? Surely there must be some way how to send the
requests async? (without explicit bindings to the response queues)
The reply-to address doesn't have to be a queue of course, to be
completely generic it should handle any exchange/routing-key pair (at
least in AMQP 0-10).
OK, didn't know that. I wanted to check if this is also the case for
AMQP 0-9-1, but could not find that info in the specs. Do you know?
Prior to 0-10 it was documented as 'the destination to reply to' which
would imply it should contain an exchange name. Obviously this was not
precise enough for many cases which is why it was refined a little for
0-10.
Can you please explain what happens if I create a response queue and use
its address as the parameter of Message::setReplyTo()? According to the
specs, reply-to attribute is a combination of exchange name and routing
key. How does my queue address translate to this? Does it use the
default exchange, which I can't otherwise address?
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
