On 12/17/2010 10:17 AM, Alan Conway wrote:
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?
I wasn't being entirely literal when talking about an embedded broker. I
think you might want to embed something that does queuing like a broker,
but as you point out, actually thinking of it in terms of federation is
awkward from a configuration perspective considering the API
implementation already has all the information necessary to route the
message to the correct place.
I think the key point of the analogy is that for this use case, the user
of the API really doesn't want to have to think about the possibility of
any of the API operations failing, and so needs a way to know that it is
safe to assume they always succeed. It's possible that would just be a
fatal exception with enough information to figure out the misconfiguration.
I should also point out that the API already does a form of local
queuing for transient messages, so if you're not interested in durable
messages, then really this discussion is mostly about the blocking
semantics and error model.
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
