RabbitMQ Extension with dev mode create fake consumer at each live reload

[tobat50]

Describe the bug

When an application with RabbitMQ extension (quarkus-messaging-rabbitmq) is started with dev mode, the live reloading can create fake consumers.
This happens with the simplest consumer code possible, without any specific configuration (no property added in application.properties).

Expected behavior

No response

Actual behavior

Each time the live reloading occurs and the application restarts, a new connection is created to consume the queue. But the subscription of the last run is closed then reopenned.
In the log, the queue is reconsumed many times (once more at each reload) :

2024-10-23 11:18:28,643 INFO  [io.sma.rea.mes.rabbitmq] (Quarkus Main Thread) SRMSG17036: RabbitMQ broker configured to [localhost:63805] for channel test
2024-10-23 11:18:28,645 INFO  [io.sma.rea.mes.rabbitmq] (Quarkus Main Thread) SRMSG17007: Connection with RabbitMQ broker established for channel `test`
2024-10-23 11:18:28,645 INFO  [io.ver.rab.imp.RabbitMQClientImpl] (Quarkus Main Thread) Starting rabbitmq client                                                      
2024-10-23 11:18:28,648 INFO  [io.quarkus] (Quarkus Main Thread) code-with-quarkus 1.0.0-SNAPSHOT on JVM (powered by Quarkus 3.15.1) started in 0.269s. Listening on: http://localhost:8080                                                                                                                                                 
2024-10-23 11:18:28,648 INFO  [io.quarkus] (Quarkus Main Thread) Profile dev activated. Live Coding activated.                                                        
2024-10-23 11:18:28,648 INFO  [io.quarkus] (Quarkus Main Thread) Installed features: [cdi, messaging, messaging-rabbitmq, resteasy-jackson, smallrye-context-propagation, vertx]                                                                                                                                                            
2024-10-23 11:18:28,649 INFO  [io.qua.dep.dev.RuntimeUpdatesProcessor] (Aesh InputStream Reader) Live reload total time: 0.290s                                       
2024-10-23 11:18:28,662 INFO  [io.sma.rea.mes.rabbitmq] (vert.x-eventloop-thread-2) SRMSG17007: Connection with RabbitMQ broker established for channel `test`        
2024-10-23 11:18:28,664 INFO  [io.sma.rea.mes.rabbitmq] (vert.x-eventloop-thread-2) SRMSG17000: RabbitMQ Receiver listening address test
2024-10-23 11:18:35,928 INFO  [io.ver.rab.imp.RabbitMQClientImpl] (vert.x-eventloop-thread-7) Successed to restart client.                                            
2024-10-23 11:18:35,945 INFO  [io.ver.rab.imp.RabbitMQClientImpl] (vert.x-worker-thread-27) Reconsume queue: test success
2024-10-23 11:18:35,951 INFO  [io.ver.rab.imp.RabbitMQClientImpl] (vert.x-eventloop-thread-10) Successed to restart client. 
2024-10-23 11:18:35,956 INFO  [io.ver.rab.imp.RabbitMQClientImpl] (vert.x-worker-thread-28) Reconsume queue: test success                                             
2024-10-23 11:18:36,365 INFO  [io.ver.rab.imp.RabbitMQClientImpl] (vert.x-eventloop-thread-13) Successed to restart client.                                           
2024-10-23 11:18:36,370 INFO  [io.ver.rab.imp.RabbitMQClientImpl] (vert.x-worker-thread-28) Reconsume queue: test success
2024-10-23 11:18:36,598 INFO  [io.ver.rab.imp.RabbitMQClientImpl] (vert.x-eventloop-thread-16) Successed to restart client.                                           
2024-10-23 11:18:36,610 INFO  [io.ver.rab.imp.RabbitMQClientImpl] (vert.x-worker-thread-28) Reconsume queue: test success
2024-10-23 11:18:37,676 INFO  [io.ver.rab.imp.RabbitMQClientImpl] (vert.x-eventloop-thread-19) Successed to restart client.                                           
2024-10-23 11:18:37,681 INFO  [io.ver.rab.imp.RabbitMQClientImpl] (vert.x-worker-thread-28) Reconsume queue: test success
2024-10-23 11:18:37,855 INFO  [io.ver.rab.imp.RabbitMQClientImpl] (vert.x-eventloop-thread-22) Successed to restart client.                                           
2024-10-23 11:18:37,859 INFO  [io.ver.rab.imp.RabbitMQClientImpl] (vert.x-worker-thread-28) Reconsume queue: test success
2024-10-23 11:18:38,354 INFO  [io.ver.rab.imp.RabbitMQClientImpl] (vert.x-eventloop-thread-25) Successed to restart client.                                           
2024-10-23 11:18:38,364 INFO  [io.ver.rab.imp.RabbitMQClientImpl] (vert.x-worker-thread-28) Reconsume queue: test success

How to Reproduce?

The issue can be reproduced with a very simple setup.

1. Create a project with the quarkus-messaging-rabbitmq extension. Use the RabbitMQ dev service, with default configuration
2. The only code file in the project is the consumer, with no treatment inside :

@ApplicationScoped
public class RabbitMQTest {

    @Incoming("test")
    void incoming(String message) {

    }

}

3. Let the application.properties empty
4. Run the project in dev mode mvn quarkus:dev
5. In the RabbitMQ management UI, the queue test is consumed by only one consumer
6. Do some live reload, by pressing s key
7. After performing live reloads, check the RabbitMQ management UI. You'll notice that the queue test is now being consumed by multiple consumers :
   

Output of uname -a or ver

No response

Output of java -version

OpenJDK 64-Bit Server VM Temurin-21.0.2+13 (build 21.0.2+13-LTS, mixed mode, sharing)

Quarkus version or git rev

3.15.1

Build tool (ie. output of mvnw --version or gradlew --version)

Apache Maven 3.9.8 (36645f6c9b5079805ea5009217e36f2cffd34256) | OS name: "windows 11", version: "10.0", arch: "amd64", family: "windows"

Additional information

No response

[quarkus-bot]

/cc @cescoffier (reactive-messaging), @ozangunalp (reactive-messaging)

[gsmet]

@ozangunalp any chance you could have a look at this one? It looks annoying.

[ozangunalp]

I created an upstream issue, I'll make sure it makes it to the next release.

[ozangunalp]

In the end, this was not what I expected. The RabbitMQ consumers were not closed on shutdown, which resulted in connections being kept open between dev-mode restarts.

The upstream smallrye/smallrye-reactive-messaging#2825 fixed that and also smallrye/smallrye-reactive-messaging#2826 adds the option to set consumer tags.