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 <danlangf...@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-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

Reply via email to