qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan Conway <acon...@redhat.com>
Subject Re: Proposed Feature Removal from Dispatch Router
Date Mon, 16 Apr 2018 17:06:28 GMT
On Mon, Apr 16, 2018 at 12:39 PM, Ken Giusti <kgiusti@redhat.com> 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?
>
> 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.
>

What is the use case for this? If I cared about the disposition of a
message for multiple receivers, I'd send it on multiple unicast addresses
so I know what happened on each one. If I didn't care, I'd send multicast
and pre-settled and genuinely not care. Multicast is very useful when some
unknown number of receivers, possibly zero, can subscribe based on interest
- but the sender doesn't know or care how many there are. What's the use
case where the sender must know that the message was received by somebody
but doesn't care who or how many?

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message