I don't have an issue with this, I didn't originally like the default
being to reject unsettled deliveries when the ability was added,
particularly given the congestion handling for pre-settled, but also
due to the likely need for clients to jump hoops to use the
multicasting vs not.

The functionality could always be added back in later if it becomes
more feasible to resolve the issues, and in the meantime if the
unsettled message didnt actually go anywyere, its really no different
than the equivalent pre-settled message not actually going anywhere. I
dont see the use case being much/any different than the traditional
topic pub-sub case where there might be noone subscribed at the point
a message is sent.

Robbie

On 12 April 2018 at 23:26, Ted Ross <tr...@redhat.com> wrote:
> 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