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
Dropped connections and heartbeats causing bad_header error and infinite loop #413
Comments
Hello, I'm also concerned by this, could someone have a look ? Thanks |
Probable same issue like this issue. |
ruicampos
added a commit
to smarkio/php-amqplib
that referenced
this issue
Apr 21, 2017
This is affecting consumers when it takes more than 2*heartbeat time to process a message. When trying to close the connection, library will: * check the heartbeat * detect that it passed more than 2*times the heartbeat value without receiving anything * considers that server has gone away and tries to reconnect * after reconnecting as it is not clearing internal variables with time of last read, it will check the heartbeat again and try to reconnect again in loop. There are already issues on the library's github: php-amqplib#309 and php-amqplib#413
ruicampos
added a commit
to ruicampos/php-amqplib
that referenced
this issue
Apr 21, 2017
The problem this PR fixes is: * StreamConnection with heartbeat is created (e.g. heartbeat=10 seconds) * Start consuming messages from the queue * If one of the messages take more than 2*heartbeat interval to process (e.g. 30 seconds), the next time it tries to read something from Rabbit it will check_heartbeat() * As it finds that it passed more than 2*heartbeat, it will reconnect() * But as it does not reset the values of last_read and last_write, after reconnect it will do the check_heartbeat() again and as it is based on last_read, it will try to reconnect again * It keeps trying to reconnect in infinite loop This PR fixes issues: php-amqplib#413 and php-amqplib#309
Hopefully should be addressed by #479. |
escudeiro
pushed a commit
to smarkio/php-amqplib
that referenced
this issue
Apr 24, 2017
This is affecting consumers when it takes more than 2*heartbeat time to process a message. When trying to close the connection, library will: * check the heartbeat * detect that it passed more than 2*times the heartbeat value without receiving anything * considers that server has gone away and tries to reconnect * after reconnecting as it is not clearing internal variables with time of last read, it will check the heartbeat again and try to reconnect again in loop. There are already issues on the library's github: php-amqplib#309 and php-amqplib#413
kratkyzobak
pushed a commit
to kratkyzobak/php-amqplib
that referenced
this issue
Feb 9, 2024
The problem this PR fixes is: * StreamConnection with heartbeat is created (e.g. heartbeat=10 seconds) * Start consuming messages from the queue * If one of the messages take more than 2*heartbeat interval to process (e.g. 30 seconds), the next time it tries to read something from Rabbit it will check_heartbeat() * As it finds that it passed more than 2*heartbeat, it will reconnect() * But as it does not reset the values of last_read and last_write, after reconnect it will do the check_heartbeat() again and as it is based on last_read, it will try to reconnect again * It keeps trying to reconnect in infinite loop This PR fixes issues: php-amqplib#413 and php-amqplib#309
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We have a connection going on between a datacenter and amazon AWS through a elastic load balancer. When trying to secure this connection using SSL, I've bumped into a problem.
When using SSL for the stream, keepalive can no longer be enabled (see issue #371). So I decided to try enabling heartbeats.
After a while I found out that a lot of my php processes just hang and after a bit more investigation, they seems to be stuck at the reconnect phase, triggered by the heartbeat functionality.
It seems to me that the following happens:
The last two steps are executed indefinitely.
I tried disabling SSL, and it gives the same result.
I dug in some more and ran wireshark to figure out what was happening under the hood. When connecting for the first time, it seems that the communication goes like this:
But when the heartbeat is triggered this happens:
The rabbitmq log looks like this:
My guess is that the heartbeat is sent at the wrong time and that the Connection.Start and Connection.Start-Ok frames need to be exchanged before sending the heartbeat.
This is what I configured to reproduce this:
My test script:
The text was updated successfully, but these errors were encountered: