Skip to content
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
Closed

Can't handle heartbeat 0 from server #519

carlhoerberg opened this issue Sep 23, 2017 · 6 comments
Labels
bug

Comments

@carlhoerberg
Copy link
Contributor

@carlhoerberg 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
Copy link
Member

@michaelklishin michaelklishin commented Sep 23, 2017

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

@carlhoerberg
Copy link
Contributor Author

@carlhoerberg carlhoerberg commented Sep 23, 2017

@michaelklishin
Copy link
Member

@michaelklishin 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
Copy link
Contributor Author

@carlhoerberg carlhoerberg commented Sep 23, 2017

@michaelklishin
Copy link
Member

@michaelklishin 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
Copy link
Member

@michaelklishin 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
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
…imeouts

References #519.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.