On Thu, 16 Dec 2010, 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.
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.
You're stating it much better than I could. In fact, thanks to everyone
who's responded. It has corrected my misconceptions and spurred my
thoughts.
Justin
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
