qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Ross <jr...@redhat.com>
Subject Re: A criticism of the new messaging API
Date Fri, 17 Dec 2010 20:14:12 GMT
On Fri, 17 Dec 2010, Rafael Schloming wrote:

> 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
>>>>> produce up to <capacity> messages with the connection never having
>>>>> 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.

I think the question is whether it's a programming concern or an 
administrative one.  For my app, I want connection status to be an 
administrative concern.

The comparison to federation helps.  In the case of a A->B->C broker path, 
where B drops out, how would we report errors?  Will we need a notion of, 
say, undeliverable messages, like smtp has?  I think the problem of 
propogating the error back is the same whether the thing queueing is 
in-process or out-of-process.


Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org

View raw message