Repository navigation
ZOOKEEPER-4947: Stop the send loop after SASL authentication fails - #2443
Conversation
ZooKeeper.close() treated AUTH_FAILED clients as already closed and skipped prompt shutdown of their connection threads. Signed-off-by: 1fanwang <1fannnw@gmail.com>
I checked the reproduction steps from ZOOKEEPER-4947 and think the behavior is temporary as |
|
Withdraw my +1. I think what we need to do is quiting send loop right after |
Signed-off-by: 1fanwang <1fannnw@gmail.com>
Signed-off-by: 1fanwang <1fannnw@gmail.com>
|
Done in 2dd3c44. The send loop now exits on AUTH_FAILED without caller close; the description is corrected. |
|
Thanks for the contribution @1fanwang . I restarted the failing build, but the unit test failure might be related, I'm not sure. |
Wait for AuthFailed on intentionally rejected clients rather than requiring their server connection to remain registered in JMX. Signed-off-by: 1fanwang <1fannnw@gmail.com>
|
Done in 60ad965. Rejected-client tests now wait for AuthFailed instead of a transient JMX entry; the AUTHFAILED assertions remain. |
Reviewers: kezhuw, anmolnar Author: 1fanwang Closes #2443 from 1fanwang/fix-zookeeper-4947-auth-failed-close (cherry picked from commit 92f1040) Signed-off-by: Andor Molnar <andor@apache.org>
|
Merged to |
|
What is your jira id? |
Thanks @anmolnar My ASF Jira info is: |
Great. I added you to the contributors list. |
After SASL authentication fails, the send thread can remain in a transport wait. It eventually exits; the event thread already stops. Break out at the authentication-failure branch before another transport wait, so the existing cleanup runs without caller close. The client retains
AUTH_FAILED; explicit close still setsCLOSED.https://issues.apache.org/jira/browse/ZOOKEEPER-4947
Testing Done
The bad-DIGEST fixture uses a real file-backed loopback server and a 30-second session. It logs shutdown before close with a one-second bound per thread, then asserts shutdown, the retained failure state and request error.
Rejected-client fixtures wait for the AuthFailed event rather than requiring a live JMX connection entry. CI previously failed in that bookkeeping check with
expected: <1> but was: <0>after rejection had removed the entry. Valid-client JMX checks and the failed clients' state and request assertions remain.From this PR's checkout, apply only its test changes to the baseline:
With JDK 25 and cached Maven dependencies, run this in the baseline and PR checkouts:
Both baseline runs exited 1 with:
The baseline observations below are NIO followed by Netty:
After the fix, both runs exited 0: