On 12/16/2010 03:22 PM, Rafael Schloming wrote:
On 12/15/2010 01:14 PM, Gordon Sim wrote:
On 12/15/2010 05:52 PM, Ted Ross wrote:
Keeping it simple, I would like to be able to create a connection with
reconnect enabled, a session, a sender (with a capacity) and be able to
produce up to <capacity> messages with the connection never having been
established.
Right, I see that as essentially asynchronous session and sender
creation. Seems reasonable to consider along with other improvements for
asynchronous use. A key part of that is figuring out how we will then
signal the fact that when the connection is established, the broker
informs us there is no such queue to send to (for example). Also need to
determine how you keep the current synchronous behaviour where desired.
I agree allowing async session and sender creation would be good, however I
think in some ways what Justin wants is almost simpler than that (conceptually
at least). I think what he wants is to be able to assume that the API is fully
synchronous but communicating to an embedded broker. If that broker dies or is
misconfigured then its fine if it takes his whole process down, but I don't
think he wants to have to worry about handling asynchronous errors from each
individual API operation.
The ultimate goal however is to communicate with some non-embedded target
broker. If you embed a broker (or use a local broker) then you need to set up
federation rules between the embedded broker and the target broker. So the
problem has just been moved to setting up those federation rules if the target
broker is down. Do our current federation tools allow you to do this? If so
how/when do they communicate error information if the expected queues/exchanges
don't exist on the target broker?
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
