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
|