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.
>
>
>
>>
>>
>> -K
>>
>>
>> On Mon, Apr 16, 2018 at 10:51 AM, Michael Goulish <mgoul...@redhat.com>
>> wrote:
>> > You mean your rules to be applied exclusively, and in that order, right?
>> > i.e.
>> >
>> > if ( anybody rejected )
>> > {
>> > disposition = rejected
>> > }
>> > *else*
>> > if ( anybody accepted )
>> > {
>> > disposition = accepted
>> > }
>> >
>> >
>> >
>> >
>> > On Mon, Apr 16, 2018 at 10:24 AM, Ken Giusti <kgiu...@redhat.com> wrote:
>> >
>> >> To reply to my own question:
>> >>
>> >> IMHO when sending an unsettled multicast I would expect
>> >> 1) that all present consumers will get a copy of the message and:
>> >> 2) that any potential consumers that are *not* present would not get a
>> >> copy of the message (right, that's a no-brainer, but hear me out).
>> >> 3) if any consumer signals a REJECT
>> >>
>> >> So I would like the router to:
>> >>
>> >> 1) send back a final disposition of REJECT if *any* client returned a
>> >> REJECT.
>> >> The spec is pretty clear that the message is considered invalid by the
>> >> recipient
>> >> in this case. That's a pretty big deal, since I assumed that the
>> message
>> >> is
>> >> not invalid when it was sent. This could possibly indicate a bug or a
>> >> state
>> >> mismatch between sender and receiver. I would want to know about this.
>> >>
>> >> 2) send back a final disposition of ACCEPTED if at least one client
>> >> ACCEPTED. Ignore MODIFIED and RELEASED in this case, since
>> >> 2a) RELEASED indicates we can resend safely, which we cannot
>> >> (someone ACCEPTED)
>> >> 2b) MODIFIED is in doubt, also cannot resend safely and I feel can
>> >> be considered as an equivalent case as #2 above
>> >>
>> >> 3) Otherwise for a mix of MODIFIED and RELEASED return MODIFIED as we
>> >> cannot re-send the same message.
>> >> 4) else all RELEASED, so return RELEASED.
>> >>
>> >>
>> >>
>> >> Again, this is MHO and I only present it as a strawman for
>> >> consideration and discussion. I'm not convinced holding state in the
>> >> router while it waits
>> >> for all consumers to reply is practical (or desired in the slow consumer
>> >> case).
>> >>
>> >>
>> >> -K
>> >>
>> >> On Mon, Apr 16, 2018 at 9:49 AM, Ken Giusti <kgiu...@redhat.com> wrote:
>> >> > We really should try to do something smarter in the case of unsettled
>> >> > multicast rather than either of the current approaches.
>> >> >
>> >> > What does an application/dev expect when it sends any message
>> >> > unsettled? It expects to block until eventually it gets some
>> >> > indication of whether or not the message was delivered as intended.
>> >> > In the case of single consumer the expectation is obvious and well
>> >> > handled by the router.
>> >> >
>> >> > But in the case of multicast it is a different story: here we have the
>> >> > possibility that the message may be both consumed by one recipient and
>> >> > rejected by another. So the question is: from the POV of the dev/app,
>> >> > what is the "obvious" default action the router should perform in that
>> >> > case?
>> >> >
>> >> > -K
>> >> >
>> >> >
>> >> > On Fri, Apr 13, 2018 at 3:38 PM, Chuck Rolke <cro...@redhat.com>
>> wrote:
>> >> >> I would prefer to keep the feature enforced as it is now. I was one
>> who
>> >> >> was surprised to have a sender whose message is settled by the router
>> >> >> only to find out that it was not delivered anywhere.
>> >> >>
>> >> >> The document https://qpid.apache.org/releases/qpid-dispatch-1.0.0/
>> >> book/book.html#routing-patterns
>> >> >> needs to have a clearer explanation of the lossy nature of multicast
>> >> >> distribution.
>> >> >>
>> >> >> ----- Original Message -----
>> >> >>> From: "Ted Ross" <tr...@redhat.com>
>> >> >>> To: users@qpid.apache.org
>> >> >>> Sent: Thursday, April 12, 2018 6:26:34 PM
>> >> >>> Subject: Re: Proposed Feature Removal from Dispatch Router
>> >> >>>
>> >> >>> For the record, here is the Jira for the feature in question:
>> >> >>>
>> >> >>> https://issues.apache.org/jira/browse/DISPATCH-744
>> >> >>>
>> >> >>> On Thu, Apr 12, 2018 at 6:20 PM, Ted Ross <tr...@redhat.com> wrote:
>> >> >>> > We added a feature back in 1.0.0 to reject unsettled deliveries to
>> >> >>> > multicast addresses by default. This can be disabled through
>> >> >>> > configuration but is on by default.
>> >> >>> >
>> >> >>> > The rationale was that the router would accept and settle
>> unsettled
>> >> >>> > multicasts even though it might not have delivered the messages to
>> >> any
>> >> >>> > consumer. The rejection with error code was intended to inform
>> users
>> >> >>> > that they should pre-settle deliveries to multicast addresses in
>> >> >>> > keeping with the best-effort nature of multicast routing.
>> >> >>> >
>> >> >>> > In practice, this is more of an annoyance because none of the
>> example
>> >> >>> > clients (and apparently the users' clients) actually do anything
>> with
>> >> >>> > the error code in the rejected delivery. The router appears to
>> >> >>> > silently drop such messages for no good reason and good will is
>> >> wasted
>> >> >>> > in chasing down the issue to "oh, you should turn off this handy
>> >> >>> > feature".
>> >> >>> >
>> >> >>> > The recently raised https://issues.apache.org/
>> >> jira/browse/DISPATCH-966
>> >> >>> > is caused by this feature as well. This is because the router can
>> >> >>> > stream large messages in multiple transfers. The first transfer
>> is
>> >> >>> > used for routing and the last transfer should be used to determine
>> >> the
>> >> >>> > settlement status of the delivery. It is not a trivial fix to
>> make
>> >> >>> > this work correctly.
>> >> >>> >
>> >> >>> > For the above two reasons, I propose that we back out this feature
>> >> and
>> >> >>> > allow multicasting with unsettled deliveries. We should add a
>> clear
>> >> >>> > note in the documentation that states that multicast is
>> best-effort,
>> >> >>> > regardless of the settlement status of the deliveries.
>> >> >>> >
>> >> >>> > Any objections from the users?
>> >> >>> >
>> >> >>> > -Ted
>> >> >>>
>> >> >>> ------------------------------------------------------------
>> ---------
>> >> >>> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
>> >> >>> For additional commands, e-mail: users-h...@qpid.apache.org
>> >> >>>
>> >> >>>
>> >> >>
>> >> >> ------------------------------------------------------------
>> ---------
>> >> >> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
>> >> >> For additional commands, e-mail: users-h...@qpid.apache.org
>> >> >>
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > -K
>> >>
>> >>
>> >>
>> >> --
>> >> -K
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
>> >> For additional commands, e-mail: users-h...@qpid.apache.org
>> >>
>> >>
>>
>>
>>
>> --
>> -K
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
>> For additional commands, e-mail: users-h...@qpid.apache.org
>>
>>
--
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
