[broker-j 7.0.3] TTL expire to alt binding

[Dan Langford <da...@gmail.com>]

is there way to configure the broker to treat TTL expired messages as other
"undeliverable" messages by delivering those to the configured Alternate
Binding?

Re: [broker-j 7.0.3] TTL expire to alt binding

[Rob Godfrey <ro...@gmail.com>]

Not currently, but I do think that is a sensible feature to add to the
broker.

There is, in fact, already a JIRA for this enhancement:
https://issues.apache.org/jira/browse/QPID-7153

-- Rob

On Tue, 15 May 2018 at 22:11, Dan Langford <da...@gmail.com> wrote:

> is there way to configure the broker to treat TTL expired messages as other
> "undeliverable" messages by delivering those to the configured Alternate
> Binding?
>

Re: [broker-j 7.0.3] TTL expire to alt binding

[Rob Godfrey <ro...@gmail.com>]

On Wed, 16 May 2018 at 11:12, Keith W <ke...@gmail.com> wrote:

> Hi Dan,
>
> No, unfortunately, Broker-J currently does not have that feature.
> Currently messages that get TTL'd get unconditionally deleted.
>
> Adding basic support for this feature probably would not be too much
> work but is not currently a road-map item.  The queue's model would
> need to indicate what TTL behaviour is desired (drop or route to
> alternate) and the implementation would need to internally take steps
> to avoid TTL delivery loops forming (at least within a single broker
> uptime).
>

I wonder if the solution to the loops problem is to only actually route
"expired" messages to alternates which have an "minimum message ttl" which
would leave the message not-expired on the alternate queue.  It makes no
sense to allow an expired message to be enqueued on a queue which is
immediately going to re-expire it.

-- Rob


>
> I notice that RabbitMQ's adds an "x-death" header [1] to messages
> carrying information about why the message is being dead lettered.
> I guess this was added to allow an application processing the contents
> of a dead letter queue to take appropriate actions. An analogous
> feature in Broker-J would present some challenges. Firstly, with the
> older AMQP protocols (AMQP 0-8..0-10) the Broker treats the message
> headers as immutable (for reasons of spec compliance and performance)
> so this would not be a possibility.  In AMQP 1.0 augmenting the
> message with an annotation [2] is allowed so I expect this would be a
> possibility for this use-case.  However, the Broker's internals would
> need considerable refactoring to support this (messages store would
> need to be reworked).
>
> cheers
> Keith
>
> [1] https://www.rabbitmq.com/dlx.html
> [2]
> http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-messaging-v1.0-os.html#type-delivery-annotations
>
>
>
>
>
>
> On 15 May 2018 at 21:10, Dan Langford <da...@gmail.com> wrote:
> > is there way to configure the broker to treat TTL expired messages as
> other
> > "undeliverable" messages by delivering those to the configured Alternate
> > Binding?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>

Re: [broker-j 7.0.3] TTL expire to alt binding

[Keith W <ke...@gmail.com>]

Hi Dan,

No, unfortunately, Broker-J currently does not have that feature.
Currently messages that get TTL'd get unconditionally deleted.

Adding basic support for this feature probably would not be too much
work but is not currently a road-map item.  The queue's model would
need to indicate what TTL behaviour is desired (drop or route to
alternate) and the implementation would need to internally take steps
to avoid TTL delivery loops forming (at least within a single broker
uptime).

I notice that RabbitMQ's adds an "x-death" header [1] to messages
carrying information about why the message is being dead lettered.
I guess this was added to allow an application processing the contents
of a dead letter queue to take appropriate actions. An analogous
feature in Broker-J would present some challenges. Firstly, with the
older AMQP protocols (AMQP 0-8..0-10) the Broker treats the message
headers as immutable (for reasons of spec compliance and performance)
so this would not be a possibility.  In AMQP 1.0 augmenting the
message with an annotation [2] is allowed so I expect this would be a
possibility for this use-case.  However, the Broker's internals would
need considerable refactoring to support this (messages store would
need to be reworked).

cheers
Keith

[1] https://www.rabbitmq.com/dlx.html
[2] http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-messaging-v1.0-os.html#type-delivery-annotations






On 15 May 2018 at 21:10, Dan Langford <da...@gmail.com> wrote:
> is there way to configure the broker to treat TTL expired messages as other
> "undeliverable" messages by delivering those to the configured Alternate
> Binding?

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