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.
It may be that this distinction isn't important, or that an async model
can accommodate his needs, but I think it's important to understand what
his use case actually is.
Please correct me if I'm putting words in your mouth, Justin.
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
