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 <[email protected]> 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: [email protected] For additional commands, e-mail: [email protected]
