-
Notifications
You must be signed in to change notification settings - Fork 303
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
Comments
I am inclined to treat this as a feature: disabling heartbeats is a terrible idea. |
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>.
|
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:
|
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>
.
|
@carlhoerberg that was my first guess. So far I'm unable to prove that hypothesis. |
@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 |
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.
rabbitmq.config:
client:
exception:
The text was updated successfully, but these errors were encountered: