Closed AdminBenni closed 1 year ago
Thanks for the detailed bug report, it's super helpful.
I believe that RabbitMQ is in violation of the AMQP 1.0 spec, specifically section 2.6.6.
Note that one peer MAY send a closing detach while its partner is sending a non-closing detach. In this case, the partner MUST signal that it has closed the link by reattaching and then sending a closing detach.
Here you can see that go-amqp
sent the Detach
performative to RabbitMQ indicating it's closing the link.
TX (connWriter 0xc000002180) timeout 30s: Frame{Type: AMQP, Channel: 0, Body: Detach{Handle: 1, Closed: true, Error: *Error(nil)}}
However, RabbitMQ responds with a non-closing Detach
performative.
RX (connReader 0xc000002180): Frame{Type: AMQP, Channel: 0, Body: Detach{Handle: 1, Closed: false, Error: *Error(nil)}}
While this is ok (although I don't think the Detach
performatives were simultaneously sent), per section 2.6.6, RabbitMQ MUST reattach the link and send a closing Detach
performative.
Are there any logs etc on the RabbitMQ side that might indicate why it didn't close the link? In the meantime, you'll want to use a context.Context
with a deadline/timeout when calling close to avoid the hang.
Thanks so much for the quick response. Thanks to your insight we have already switched to ActiveMQ and it works without issue.
In regards to the RabbitMQ logs, unfortunately, even with the highest verbosity setting, they don't tell us much.
2023-09-13 16:02:23.457469+00:00 [info] <0.534.0> Server startup complete; 5 plugins started.
2023-09-13 16:02:23.457469+00:00 [info] <0.534.0> * rabbitmq_prometheus
2023-09-13 16:02:23.457469+00:00 [info] <0.534.0> * rabbitmq_amqp1_0
2023-09-13 16:02:23.457469+00:00 [info] <0.534.0> * rabbitmq_management
2023-09-13 16:02:23.457469+00:00 [info] <0.534.0> * rabbitmq_management_agent
2023-09-13 16:02:23.457469+00:00 [info] <0.534.0> * rabbitmq_web_dispatch
2023-09-13 16:02:23.457568+00:00 [debug] <0.534.0> Marking RabbitMQ as running
2023-09-13 16:02:23.457593+00:00 [debug] <0.534.0> Change boot state to `ready`
2023-09-13 16:02:23.457635+00:00 [debug] <0.134.0> Boot state/systemd: notifying of state `ready`
2023-09-13 16:02:23.588281+00:00 [debug] <0.9.0> Time to start RabbitMQ: 4707285 us
2023-09-13 16:02:38.221522+00:00 [info] <0.684.0> accepting AMQP connection <0.684.0> (172.18.0.1:55032 -> 172.18.0.2:5672)
2023-09-13 16:02:38.222850+00:00 [debug] <0.684.0> User 'guest' authenticated successfully by backend rabbit_auth_backend_internal
2023-09-13 16:02:38.222921+00:00 [info] <0.684.0> AMQP 1.0 connection <0.684.0>: user 'guest' authenticated
2023-09-13 16:02:38.224060+00:00 [debug] <0.684.0> AMQP 1.0 connection.open frame: hostname = localhost, extracted vhost = /, idle_timeout = 60000
2023-09-13 16:02:38.225625+00:00 [warning] <0.691.0> AMQP 0-9-1 client call timeout was 70000 ms, is updated to a safe effective value of 130000 ms
2023-09-13 16:02:38.230534+00:00 [debug] <0.695.0> User 'guest' authenticated successfully by backend rabbit_auth_backend_internal
2023-09-13 16:02:38.231800+00:00 [debug] <0.684.0> AMQP 1.0 opened channel = {0,<0.691.0>}
2023-09-13 16:02:38.231850+00:00 [info] <0.684.0> AMQP 1.0 connection <0.684.0>: user 'guest' authenticated and granted access to vhost '/'
2023-09-13 16:02:38.615953+00:00 [debug] <0.736.0> User 'guest' authenticated successfully by backend rabbit_auth_backend_internal
2023-09-13 16:02:38.624706+00:00 [debug] <0.744.0> User 'guest' authenticated successfully by backend rabbit_auth_backend_internal
Glad you found a solution. I'm going to close this issue then given that RabbitMQ is doing the wrong thing.
We are connecting to a local RabbitMQ instance and everything works until it comes to closing the sender/receiver, where it hangs.
Here is the debug log from the code above.