On 06/30/2011 05:38 AM, Jiri Krutil wrote:

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)

Yes, I agree that in that use case it would be useful to bypass the passive declare. Perhaps an overloaded createSender() with an explicit sync flag?

Having a pseudonym for the default exchange might also address your original aim to create a sender to that exchange. My concern there is whether that would be relevant outside the specific protocol version(s) defining such an exchange.

I think the fully async creation of senders is a nicer solution. Thoughts?

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?

Yes.

---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:[email protected]

Reply via email to