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