On 16 April 2018 at 19:24, Ken Giusti <kgiu...@redhat.com> wrote:
> 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.
>

One thing it lets you know is that it actually reached and was
processed by a router. It also means you dont have to explicitly
reconfigure your clients behaviour to use presettled or not unless you
want to. E.g imagine you want to drop routers in front of/inbetween
some clients or brokers, where you were previously using unsettled
messages against a single broker, it might be nice not to have to
recongiure the clients.

...and now I've actually read your next mail I think I'm partially
repeating what you said, oh well :)

Robbie

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

Reply via email to