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?
What if all consumers never return a disposition?
What if there are no consumers?
>
>
> -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
>
>
