On Wed, 16 May 2018 at 11:12, Keith W <[email protected]> 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 <[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] > >
