On Mon, Apr 16, 2018 at 1:06 PM, Alan Conway <acon...@redhat.com> wrote: > On Mon, Apr 16, 2018 at 12:39 PM, Ken Giusti <kgiu...@redhat.com> 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? >> >> 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.
You and I both. But the original question I posited is "what does a user/app expect if they send multicast unsettled?" I'm trying to understand what people expect to happen when they do this. Right now we provide two solutions, one to explicitly fail unless they set the "no, I know what I'm doing" switch. In that case, we settle it locally, which is a subtle fake that may lead to unanticipated behaviors. > 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? I can't see one honestly. If no one else does then the correct behavior should always be REJECT, since anything else is undefined. -- -K --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
