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
Description:
I have a websocket server. Clients connect and request data for different redis streams. The main event loop for the websocket does a blocking xread command on the requested stream (block=0), and when data is available it sends it out through the websocket.
If the websocket client disconnects, there is no way to interrupt the blocking xread command on the server side, and the event loop task is just killed off.
This results in the finally clause of the redis client execute_command method being invoked, which releases the connection back into the connection pool. At this point though, the connection itself is stuck on a blocking read from redis, waiting for a response to the xread command.
At some point in the future, the connection is then given out from the pool to a new client, but the connection is still stuck on the blocking read, and won't do anything until a message arrives in the stream, causing some odd behavior in the new client that is trying to use the connection.
Would it be possible to detect if a connection is stuck like this when releasing it back into the pool, and clean it up if so?
In the mean time I can use a polled approach to reading from the stream, but any advice on how to implement this with a blocking read would be appreciated.
The text was updated successfully, but these errors were encountered:
Version: redis-py = 4.5.3 redis = 7.0.5
Platform: Python 3.9 on Mac Ventura (M1 hardware)
Description:
I have a websocket server. Clients connect and request data for different redis streams. The main event loop for the websocket does a blocking xread command on the requested stream (block=0), and when data is available it sends it out through the websocket.
If the websocket client disconnects, there is no way to interrupt the blocking xread command on the server side, and the event loop task is just killed off.
This results in the finally clause of the redis client execute_command method being invoked, which releases the connection back into the connection pool. At this point though, the connection itself is stuck on a blocking read from redis, waiting for a response to the xread command.
At some point in the future, the connection is then given out from the pool to a new client, but the connection is still stuck on the blocking read, and won't do anything until a message arrives in the stream, causing some odd behavior in the new client that is trying to use the connection.
Would it be possible to detect if a connection is stuck like this when releasing it back into the pool, and clean it up if so?
In the mean time I can use a polled approach to reading from the stream, but any advice on how to implement this with a blocking read would be appreciated.
The text was updated successfully, but these errors were encountered: