qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan Conway <acon...@redhat.com>
Subject Re: A criticism of the new messaging API
Date Fri, 17 Dec 2010 15:17:28 GMT
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:dev-subscribe@qpid.apache.org


Mime
View raw message