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
