Can't handle heartbeat 0 from server

[carlhoerberg]

rabbitmq.config:

[
  {rabbit, [
    {heartbeat, 0}
  ]}
].

client:

require 'bunny'
Bunny.new("amqp://guest:guest@localhost").start

exception:

E, [2017-09-23T11:10:23.309983 #41848] ERROR -- #<Bunny::Session:0x7f7fd9029490 guest@localhost:5672, vhost=/, addresses=[localhost:5672]>: Got an exception when receiving data: IO timeout when reading 7 bytes (Timeout::Error)
W, [2017-09-23T11:10:23.310777 #41848]  WARN -- #<Bunny::Session:0x7f7fd9029490 guest@localhost:5672, vhost=/, addresses=[localhost:5672]>: An empty frame was received while opening the connection. In RabbitMQ <= 3.1 this could mean an authentication issue.
/Users/carl/.rbenv/versions/2.4.1/lib/ruby/gems/2.4.0/gems/bunny-2.7.0/lib/bunny/session.rb:327:in `rescue in start': Could not establish TCP connection to any of the configured hosts (Bunny::TCPConnectionFailedForAllHosts)
        from /Users/carl/.rbenv/versions/2.4.1/lib/ruby/gems/2.4.0/gems/bunny-2.7.0/lib/bunny/session.rb:295:in `start'
        from test/ruby.rb:2:in `<main>'

[michaelklishin]

I am inclined to treat this as a feature: disabling heartbeats is a terrible idea.

[carlhoerberg]

Not if TCP keep alive is enabled, then it simplifies things a lot.

…

On 23 Sep 2017, at 11:51, Michael Klishin ***@***.***> wrote: I am inclined to treat this as a feature: disabling heartbeats is a terrible idea. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#519 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAK_TgbzhMxbUBSXknAEBx5GR8DM5M5Gks5slNS8gaJpZM4Phfun>.

[michaelklishin]

A quick look doesn't make it obvious what's going on: there's a default read timeout on the socket and heartbeat sender isn't started until after connection is negotiated.

However, Wireshark reveals it's the client that closes the connection:

49	16.680471	127.0.0.1	127.0.0.1	TCP	56	65110 → 5672 [FIN, ACK] Seq=399 Ack=529 Win=407776 Len=0 TSval=953851427 TSecr=953851427

[carlhoerberg]

May it be that Bunny sets its TCP read timeout to 0 when the heartbeat is 0?

…

On Sep 23, 2017 12:19, "Michael Klishin" ***@***.***> wrote: A quick look doesn't make it obvious what's going on: there's a default read timeout on the socket and heartbeat sender isn't started after connection is negotiated. However, Wireshark reveals it's the client that closes the connection: 49 16.680471 127.0.0.1 127.0.0.1 TCP 56 65110 → 5672 [FIN, ACK] Seq=399 Ack=529 Win=407776 Len=0 TSval=953851427 TSecr=953851427 — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#519 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAK_ThJg0olTBE9bpBtpbfVZt7mBU8F5ks5slNtLgaJpZM4Phfun> .

[michaelklishin]

@carlhoerberg that was my first guess. So far I'm unable to prove that hypothesis.

[michaelklishin]

@carlhoerberg so your hypothesis was right but it was slightly more complicated. By default Bunny will use RabbitMQ's heartbeat value but the code only checked its own value for whether it is 0.