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.
-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
