quarkusio / quarkus

Quarkus: Supersonic Subatomic Java.
https://quarkus.io
Apache License 2.0
13.36k stars 2.56k forks source link

RabbitMQ Message not nacked in case of queue limit #41629

Open soframel opened 2 days ago

soframel commented 2 days ago

Describe the bug

I am trying to work with quarkus-smallrye-reactive-messaging-rabbitmq in an environment where RabbitMQ is configured with a limited number of messages (overflow of type "reject-publish" + dead-letter-strategy=at-least-once). I am not able to get a negative acknowledgement in my Quarkus publisher application (with "publish-confirm" configured) in case the message is rejected by the RabbitMQ cluster when the queue is full: in Quarkus, I only ever get a timeout, but never a "nack":

I have created a reproducer here https://github.com/soframel/quarkus-rabbitmq-tests/tree/rabbitOverflowNotNacked using an OutgoingInterceptor to check for the ack or nack. Before that, I had also tried with a MutinyEmitter to produce a Uni, as well as with a CompletionStage on Emitter.send, with the same results.

Note: I am not sure if it is a Quarkus or Smallrye or event Vertx problem (which explains why I cross-posted on smallrye reactive messaging's discussions + stackoverflow already some time ago, but then I couldn't find the time to reproduce it until now, sorry). I thought it may have been a problem with RabbitMQ's quorum queues, but I have now tested the same cluster configuration with spring-boot using their "Confirm" object, and I directly receive a nack in case of overflow in the queue.

Expected behavior

getting third message "nacked" (unit test in reproducer should work)

Actual behavior

message is neither acked nor nacked, test fails with a timeout

How to Reproduce?

use branch "rabbitOverflowNotNacked" on project below: https://github.com/soframel/quarkus-rabbitmq-tests/tree/rabbitOverflowNotNacked

either run the unit test, or run the docker compose +the Quarkus app and try to send 3 messages using http://localhost:8080/rabbit?s=test

Output of uname -a or ver

Microsoft Windows [Version 10.0.19045.4529]

Output of java -version

openjdk 21.0.3 2024-04-16 LTS OpenJDK Runtime Environment Temurin-21.0.3+9 (build 21.0.3+9-LTS) OpenJDK 64-Bit Server VM Temurin-21.0.3+9 (build 21.0.3+9-LTS, mixed mode, sharing)

Quarkus version or git rev

3.12.0

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

Apache Maven 3.9.6 (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae) Maven home: C:\IDE\apache-maven-3.9.6 Java version: 21.0.3, vendor: Eclipse Adoptium, runtime: C:\Program Files\Temurin Default locale: en_US, platform encoding: UTF-8 OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"

Additional information

No response

quarkus-bot[bot] commented 2 days ago

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

ozangunalp commented 2 days ago

Thanks for the reproducer. I'll need some time to check but the problem may come from the Vert.x client publish implementation.

If I understand correctly when the queue is full the broker should reject the message with a nack. And the publish confirm should result in failure. We need to debug to see why this is not happening.