Hi there!

The way we use AMQProxy, we depend on it being able to perform a rolling restart (in a kubernetes cluster).
For that we send a SIGTERM to the AMQProxy.

This commit changed the SIGTERM behaviour though: 98c0bc7 (The else in L81 moved in amqproxy.cr)

Now the shutdown is not graceful anymore, since it does not only wait for all clients to disconnect voluntary, but sends a connection close message proactively to the clients.

According to the AMQP reference, that means:

After sending this method, any received methods except Close and Close-OK MUST be discarded. The response to receiving a Close after sending Close must be to send Close-Ok.

Since this is the official reference, it is also implemented like this in most AMQP client libraries and one can't ignore a connection close message. (See for example in the most popular PHP AMQP client library)

That means one is not able to e.g. finish processing the current message before shutting down, but instead it's possible, that a worker is forced to shutdown while processing a message. This can lead to messages being processed multiple times.

As a quick fix (since we build from source anyway) we use this patch on the file amqproxy/src/amqproxy.cr

--- amqproxy_original.cr	2024-08-16 16:28:59
+++ amqproxy.cr	2024-08-16 16:36:12
@@ -90,14 +90,17 @@
       if first_shutdown
         first_shutdown = false
         server.stop_accepting_clients
-        server.disconnect_clients
         if @term_timeout >= 0
           spawn do
             sleep @term_timeout
+            server.disconnect_clients
+            sleep 5
             abort "Exiting with #{server.client_connections} client connections still open"
           end
         end
       else
+        server.disconnect_clients
+        sleep 5
         abort "Exiting with #{server.client_connections} client connections still open"
       end
     end

The solutions that come to my mind would be one of these:

• The changes above to be merged (which would be a breaking change though)
• Like other servers do, there could be multiple signals - e.g. a SIGTERM could send the connection close, while maybe SIGINT could be really graceful by not sending the connection close
• A CLI option, to change the SIGTERM behaviour of whether to send a connection close or not

Would be happy to hear what you think about this :)

Thanks a lot in advance and best,
Marvin