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.
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.
What if you just allowed the Address name to be empty and let it
represent the default exchange?
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
