On 07/03/2011 08:22 AM, Jiri Krutil wrote:
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?
I think both would be useful.
In some scenarios the list of exchanges is statis and people tend to
manually pre-configure durable exchanges and don't declare anything
programmaticaly on run time. In such case you would prefer an async
version of createSender() that does not check if the exchange is there.
Even if the exchange is pre-configured, verifying that the address used
to create the sender matches an existing configuration can be useful and
helps catch setup errors early.
However, I agree that there are cases where you may want to go
asynchronous (as in your example).
Being able to address the default exchange would be great. Unless there
is some strong technical reason against it, I think it should be
possible. It is the typical thing you want in a request-response
messaging pattern, where you do *not* want to verify if the reply-to
queue exists or not.
I think in the general request-response case you want to allow for any
address, including those that involve another exchange. So to me, using
a sender to the default exchange is a special case.
What if you just allowed the Address name to be empty and let it
represent the default exchange?
I prefer something a little more explicit, e.g. a special name
(qpid.all-queues). An empty name would look too much like a syntax error
and is also too closely tied to a detail of a particular protocol version.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
