-
Notifications
You must be signed in to change notification settings - Fork 474
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make it possible to disable heartbeats #467
Comments
This is how the Ruby lib bunny makes it: |
That's what it's supposed to do. See Matthias's explanation in #83. |
No it's not because that would mean there's no way to disable heartbeats.
Almost all other client libraries supports that. If the client configures
heartbeat to 0 that should be sent to the server in the TuneOk frame, only
if the user didn't configured a heartbeat should the server's suggested
heartbeat interval be used.
…On Tue, Oct 16, 2018, 20:50 Michael Bridgen ***@***.***> wrote:
if you set a heartbeat value of 0 on the client side it will use the
server's suggested value instead of disabling it
That's what it's supposed to do. See Matthias's explanation in #83
<#83 (comment)>.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#467 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAK_TllcJTqifEZsexsX9l8h39CfCH3sks5ulipdgaJpZM4XeS4w>
.
|
Since you were so convinced that the server will accept a veto of heartbeats, I went to look at the server code: The spec is not a great guide, but for the heartbeat field it does say (merely):
Compare with, for example, the guidance for
I'm compelled to conclude that the comments in #83 were misinterpreted -- they apply to channel-max and frame-max, but not to heartbeat, at least for RabbitMQ (I'm not going to go look at any other server code!). |
Hi Guys, What's the conclusion? Can the client get option to disable the heartbeat? |
RabbitMQ clearly states that a client should be able to disable heartbeats by setting the configuration value to 0:
|
It looks to me like the documentation you linked to contradicts itself. A little higher up it also states
I'm unfamiliar with erlang, but the server code this appears to confirm this is what was implemented... tune(#'connection.tune'{channel_max = ServerChannelMax,
frame_max = ServerFrameMax,
heartbeat = ServerHeartbeat},
#amqp_params_network{channel_max = ClientChannelMax,
frame_max = ClientFrameMax,
heartbeat = ClientHeartbeat}, State) ->
[ChannelMax, Heartbeat, FrameMax] =
lists:zipwith(fun (Client, Server) when Client =:= 0; Server =:= 0 ->
lists:max([Client, Server]);
(Client, Server) ->
lists:min([Client, Server])
end,
[ClientChannelMax, ClientHeartbeat, ClientFrameMax],
[ServerChannelMax, ServerHeartbeat, ServerFrameMax]), If I interpret the above correctly, when either or both the client and server value are zero, then the maximum of the two will be used, otherwise the minimum value will be used. i.e.
So the only way to disable heartbeats is by setting both the client and server to zero. For interest, the same issue was reported with the erlang client, and they reached the same conclusion. |
Sheesh, you’d think they would have updated and clarified the documentation by now if this is something so legacy that it cannot be changed in code. 😑 |
I agree. I've raised the following rabbitmq/rabbitmq-website#1386 Going to close this as the behaviour is out of amqplibs' control |
@robross0606 perhaps it was just overlooked. The RabbitMQ docs are open-source so there is plenty of opportunity for users to contribute. |
amqp-client.js implements this pragmatically, set to zero on the client side means disable it. And amqp-client.js of course enables TCP keepalive, which is a much more reliable keepalive mechanism than AMQP heartbeats. |
It's currently not possible to disable heartbeats, if you set a heartbeat value of 0 on the client side it will use the server's suggested value instead of disabling it (sending 0 to the server in the TuneOk frame).
https://github.com/squaremo/amqp.node/blob/6ee18f27e31863f5256bc921a21f36ebf2ba5e74/lib/connection.js#L192-L198
The text was updated successfully, but these errors were encountered: