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

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?


To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

Reply via email to