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

Reply via email to