You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a result of us investigating the issue mentioned in #70 (read error on connection)
We captured Redis traffic from our live servers and investigated time periods when our error reporting system captured the read error on connection exceptions. What appears to be happening is that the Redis server sends a message to the client saying it wants to close the TCP connection. However, the client then sends a subsequent TCP packet containing a GET command a few seconds AFTER receiving the packet with the FIN flag set from the Redis server. The Redis server then responds with a RST packet because it's already sent a FIN packet for that connection. The "read error on connection" error is then fired.
Here's an example (172.31.20.xxx is the Redis Server. 172.31.13.xxx is the phpredis client):
We've not figured out why the Redis server is closing the connection, but it appears the phpredis is trying to use the connection after the server has closed it.
The text was updated successfully, but these errors were encountered:
Just as a quick update, we suspect this might be caused by: #643
We're going to try compiling a custom version of phpredis with that code removed to see if it fixes the problem (issue it addresses has been fixed upstream in php)
Thanks for the investigation and update. #70 is a bug that simply refuses to die.
What version of PHP are you using? I wonder if the problem with php streams was fixed upstream and now the workaround is no longer necessary for newer versions of php.
This is a result of us investigating the issue mentioned in #70 (read error on connection)
We captured Redis traffic from our live servers and investigated time periods when our error reporting system captured the read error on connection exceptions. What appears to be happening is that the Redis server sends a message to the client saying it wants to close the TCP connection. However, the client then sends a subsequent TCP packet containing a GET command a few seconds AFTER receiving the packet with the FIN flag set from the Redis server. The Redis server then responds with a RST packet because it's already sent a FIN packet for that connection. The "read error on connection" error is then fired.
Here's an example (172.31.20.xxx is the Redis Server. 172.31.13.xxx is the phpredis client):
We've not figured out why the Redis server is closing the connection, but it appears the phpredis is trying to use the connection after the server has closed it.
The text was updated successfully, but these errors were encountered: