-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Why are we reconnecting in check_heartbeat method? #309
Comments
Hello. Most likely because after two missed heartbeats the server will consider the connection as failed and close it on its end. This would leave the client "connected" although it is not. |
We're having this exact issue. We use the server's proposed heartbeat value. Before even sending the heartbeat, check_heartbeat detects a "gone away", tries to reconnect and effectively kills all channels without establishing them again, rendering the worker in an unusable state. |
Simply disconnect here should do the trick. (This is exactly what
This, will lead into a Just leave the reconnecting issue to outer codes. Or perhaps better missing heartbeat handling. Reconnecting without recoverying any topology (this feature which is provided in Java client though) is NAIVE, IMNSHO. |
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
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
Partially addressed by #479. |
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
#559 removed the reconnect call. |
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
In following code fragment (from StreamIO.php) we are reconnecting if server has gone away. Because of this process never terminates and keeps tying to reconnect.
Shouldn't we throw exception here instead of reopening socket again?
AFAIK If TCP connection is closed, associated AMQP connection and channels are also closed. So simply reopening socket can not recreate AMQP connection.
The text was updated successfully, but these errors were encountered: