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 <[email protected]> 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 <[email protected]> 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" <[email protected]>
>>> To: [email protected]
>>> 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 <[email protected]> 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: [email protected]
>>> For additional commands, e-mail: [email protected]
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>
>
>
> --
> -K
--
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
