For the record, here is the Jira for the feature in question:

On Thu, Apr 12, 2018 at 6:20 PM, Ted Ross <> 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
> 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:
For additional commands, e-mail:

Reply via email to