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
then log in to computer A and block the redis port, where eth0 is the network interface linking the two machines:
sudo iptables -A INPUT -p tcp -i eth0 --dport 6379 -j DROP
Note that computer B hangs indefinitely even though its connection to Redis was severed. I didn't expect this, because the R connection timeout is set low intentionally in the worker.
It turns out that if the connection is restored, computer B will eventually fail, at least on my test rig, for instance log in to computer A and run:
sudo iptables -F
Timing out and failing after the connection is restored is good behavior, but I wonder if this can be improved?
The text was updated successfully, but these errors were encountered:
bwlewis
changed the title
Worker does not timeout when connection to server is interrupted (another worker hanging issue)
Worker does not timeout when connection to server is interrupted
May 6, 2016
Consider two computers, hostnames A and B and assume Redis is running on computer A.
Start a manual doRedis R worker on computer B:
then log in to computer A and block the redis port, where
eth0
is the network interface linking the two machines:Note that computer B hangs indefinitely even though its connection to Redis was severed. I didn't expect this, because the R connection timeout is set low intentionally in the worker.
It turns out that if the connection is restored, computer B will eventually fail, at least on my test rig, for instance log in to computer A and run:
Timing out and failing after the connection is restored is good behavior, but I wonder if this can be improved?
The text was updated successfully, but these errors were encountered: