Queues with x-expiry set are stored by connection recovery topology "map" (cache)

[soer84]

Describe the bug

When using the Java client for creating Queues with the auto recovery feature in combination with auto expiry the internal knowledge of created Queues does not get cleaned up after the Queues are deleted on RabbitMQ.

I took the liberty to write a reproducer (see Reproduction steps)

The problem here seems to be the following:

When creating a Queue on RabbitMQ using a "AutorecoveringConnection" the connection internally keeps track of Queues (and also Exchanges and Topics I think). In our case, we create a Queue for a unknown third party which never connects to the Queue. Therefore, after the timeout set on the Queue (the x-expiry parameter) the Queue is deleted on RabbitMQ and therefore will not be recoverable anymore from a clients perspective. The knowledge of the Queue however will forever be known in the "AutorecoveringConnection".

In our case we could workaround it by just clearing the internal Map. as we know we will never ourselves connect to aforementioned Queue but that might not be the case for everyone.

Reproduction steps

LeakReproducer.zip

Expected behavior

The internal mechanism for Autorecovery (which is the default) takes the x-expiry flag into consideration.

Additional context

No response

[michaelklishin]

This is not a leak and neither it is a bug.

Queue TTL is applied on the server. Clients are completely unaware of this and it was never the goal for topology recovery to take queue TTL into account. Setting x-expires via an optional client argument is usually wrong, the recommended option is to use a policy.

The recovery cache is cleared when queues are deleted. Topology recovery can be disabled independently from connection (and channel) recovery on a per ConnectionFactory basis.

Since the recommended way of setting TTL is via a policy, and client libraries won't be aware of policy settings such as TTL, this is just something you have to deal with. These (potentially already expired) queues will be redeclared upon recovery.

The client could provide a way to filter out certain queues from the recovery cache. You are welcome to work on a proposal for such a feature. It hasn't been requested in the 11 years this client has had connection recovery.

Such mechanism would allow exclusive or otherwise temporary queues to be filtered out, for example.
I guess it can be a common interface that uses an "accept everything" implementation by default.

[michaelklishin]

I've filed an issue with a basic description of such a topology filtering feature #1312