On 16/04/18 17:39, Ken Giusti wrote:
On Mon, Apr 16, 2018 at 12:11 PM, Alan Conway <acon...@redhat.com> wrote:
On Mon, Apr 16, 2018 at 11:00 AM, Ken Giusti <kgiu...@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-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
