qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Sim <g...@redhat.com>
Subject Re: Proposed Feature Removal from Dispatch Router
Date Mon, 16 Apr 2018 17:11:48 GMT
On 16/04/18 17:39, Ken Giusti wrote:
> On Mon, Apr 16, 2018 at 12:11 PM, Alan Conway <aconway@redhat.com> wrote:
>> On Mon, Apr 16, 2018 at 11:00 AM, Ken Giusti <kgiusti@redhat.com> wrote:
>>
>>> Yeah,  exactly.
>>>
>>> It's as if you applied a priority to each disposition in the following
>>> order (highest first):
>>> REJECTED
>>> ACCEPTED
>>> MODIFIED
>>> RELEASED
>>>
>>> The router returns the highest priority disposition from all
>>> consumer's returned dispositions.
>>>
>>>
>> What if some consumer never returns a disposition?
> 
> Right - or classic 'slow consumer'.   Without some sort of timeout
> mechanism the transfer would stall indefinitely.
> But doesn't the same apply for unicast?

With multicast, all the messages go to all receivers, so a slow consumer 
will stall *all* transfers which eventually will prevent other consumers 
getting any more messages.

One use of multicast is for a pub-sub style communication pattern where 
you want the publishers and subscribers to be decoupled. Allowing one 
subscriber to bring message flow to a halt for publishers and all other 
subscribers might not be desirable in those cases.

> In the oslo.messaging driver, all message operations have a timeout
> and TTL.  In that
> case the sender would abort and drop the link.  Will any application
> expect to wait forever?
> Hold on - I meant to say "any well designed application"  ;)
> 
> 
>> What if all consumers never return a disposition?
> 
> Same deal.
> 
>> What if there are no consumers?
> 
> We have that now - credit is never granted and a sender can block indefinitely.

That is how anycast works now (if you already have credit then the 
messages are released). I don't think there is any credit propagation 
for multicast at present is there?

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org


Mime
View raw message