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

Can't handle heartbeat 0 from server #519

Closed
carlhoerberg opened this Issue Sep 23, 2017 · 6 comments

Comments

Projects
None yet
2 participants
@carlhoerberg
Contributor

carlhoerberg commented Sep 23, 2017

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

This comment has been minimized.

Show comment
Hide comment
@michaelklishin

michaelklishin Sep 23, 2017

Member

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

Member

michaelklishin commented Sep 23, 2017

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

@carlhoerberg

This comment has been minimized.

Show comment
Hide comment
@carlhoerberg

carlhoerberg Sep 23, 2017

Contributor
Contributor

carlhoerberg commented Sep 23, 2017

@michaelklishin

This comment has been minimized.

Show comment
Hide comment
@michaelklishin

michaelklishin Sep 23, 2017

Member

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
Member

michaelklishin commented Sep 23, 2017

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

This comment has been minimized.

Show comment
Hide comment
@carlhoerberg

carlhoerberg Sep 23, 2017

Contributor
Contributor

carlhoerberg commented Sep 23, 2017

@michaelklishin

This comment has been minimized.

Show comment
Hide comment
@michaelklishin

michaelklishin Sep 23, 2017

Member

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

Member

michaelklishin commented Sep 23, 2017

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

@michaelklishin michaelklishin added the bug label Sep 23, 2017

@michaelklishin

This comment has been minimized.

Show comment
Hide comment
@michaelklishin

michaelklishin Sep 23, 2017

Member

@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.

Member

michaelklishin commented Sep 23, 2017

@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.

michaelklishin added a commit that referenced this issue Sep 23, 2017

carlhoerberg added a commit to cloudamqp/bunny that referenced this issue Apr 26, 2018

No read timeout when waiting for next frame
Bug ruby-amqp#519 wasn't quite resolved. If heartbeats are disabled (keepalive
used instead), Bunny would use the default read_timeout when waiting for
next frame, that meant that the connection would be closed with an
exception if there was no activity for 30s.

michaelklishin added a commit that referenced this issue Apr 29, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment