jeblair
commented
6 months ago Here is a test script that will show the behavior in both async and threaded environments:
import kazoo.client
import time
import threading
import logging
logging.basicConfig(level=5)
l = logging.getLogger('kazoo')
l.setLevel(5)
client = kazoo.client.KazooClient('localhost:2181')
client.start()
def send():
client.create('/test', b'',
makepath=True, ephemeral=True, sequence=True)
def test_thread():
t = threading.Thread(target=send)
t.start()
client.stop()
def test_async():
for x in range(100):
client.create_async('/test', b'',
makepath=True, ephemeral=True, sequence=True)
client.stop()
# test_thread()
test_async()
StephenSorriaux
codecov[bot]
ceache
Revert "Fix possible endless wait in stop() after AUTH_FAILED error (#688)"
This reverts commit 5225b3e2fab6fec3b12b789e3cc6f3218429d32d.
The commit being reverted here caused kazoo not to empty the send queue before disconnecting. This means that if a client submitted asynchronous requests and then called client.stop(), the connection would be closed immediately, usually after only one (but possibly more) of the submitted requests were sent. Prior to this, Kazoo would empty the queue of submitted requests all the way up to and including the Close request when client.stop() was called.
Another area where this caused problems is in a busy multi-threaded system. One thread might decide to gracefully close the connection, but if there is any traffic generated by another thread, then the connection would end up terminating without ever sending the Close request.
Failure to gracefully shutdown a ZooKeeper connection can mean that other system components need to wait for ephemeral node timeouts to detect that a component has shutdown.
Given that this behavior is easily reproducible and can have serious consequences in production, 5225b3e2 is reverted.