Hi Asanka,

+1. Seems we need to consider all clients w:r:t a queue.
In previous model also we had a property to count number of times a message
was delivered and a delivery rule to evaluate but it was channel-wise (per
subscriber).

So if a queue or a shared durable topic subscriber has more than one
subscriber, we should consider deliveries to all consumers of that
queue/internal queue of durable topic subscriber. Let us go with that
approach.

Thanks


On Fri, Jan 12, 2018 at 10:55 AM, Asanka Abeyweera <asank...@wso2.com>
wrote:

> In the previous MB versions, we were counting the redelivery count
> independently for each consumer. But according to the spec, this is counted
> independently of the delivered consumer.
>
> The server SHOULD track the number of times a message has been delivered
>> to *clients* and when a message is redelivered a certain number of times
>> ­ e.g. 5 times ­ without being acknowledged, the server SHOULD consider the
>> message to be unprocessable (possibly causing client applications to
>> abort), and move the message to a dead letter queue.
>>
>
> Therefore we are planning to keep the redelivery count independent of the
> consumer and publish the message to DLX when the count exceeds the
> configured limit.
>
>
> On Fri, Jan 12, 2018 at 10:15 AM, Asanka Abeyweera <asank...@wso2.com>
> wrote:
>
>> Hi all,
>>
>> For message brokers, we need to provide a location to dump undeliverable
>> messages. Messages can be undeliverable due to following reasons.
>>
>>    1. Message redelivery count exceeds a configured limit.
>>    2. The queue length limit is exceeded.
>>
>> In previous versions of MB, we were using a dedicated queue (DLC) to
>> persist those undeliverable messages. This was adding some complexity in
>> handling permission and different policies with DLC. In MB4 we are planning
>> to implement a Dead Letter Exchange (DLX) instead.
>> In the first iteration of the implementation, we planning to have an
>> inbuilt DLX which is used to publish undeliverable messages. Type of the
>> DLX is of type direct. We will also create a default dead letter queue and
>> have a binding added to the DLX for the default dead letter queue. This
>> will be the default path of any undeliverable message.
>>
>> In a later iteration, we can add the capability to define custom queues
>> and exchanges for routing undeliverable messages. This will make it easy ti
>> define different policies for different dead letter scenarios.
>>
>> WDYT?
>> --
>> Asanka Abeyweera
>> Associate Technical Lead
>> WSO2 Inc.
>>
>> Phone: +94 712228648 <+94%2071%20222%208648>
>> Blog: a5anka.github.io
>>
>> <https://wso2.com/signature>
>>
>
>
>
> --
> Asanka Abeyweera
> Associate Technical Lead
> WSO2 Inc.
>
> Phone: +94 712228648
> Blog: a5anka.github.io
>
> <https://wso2.com/signature>
>



-- 
*Hasitha Abeykoon*
Associate Technical Lead; WSO2, Inc.; http://wso2.com
*cell:* *+94 719363063*
*blog: **abeykoon.blogspot.com* <http://abeykoon.blogspot.com>
_______________________________________________
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to