8000 Add concurrency test for processReadyKeys() to detect potential thread-safety issues by bhaveshthakker · Pull Request #380 · dnsjava/dnsjava · GitHub
[go: up one dir, main page]

Skip to content

Add concurrency test for processReadyKeys() to detect potential thread-safety issues #380

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

bhaveshthakker
Copy link

This PR introduces a unit test that verifies the thread-safety of NioClient.processReadyKeys() under concurrent channel registration and readiness.

The test assumes correct behavior — i.e., no ConcurrentModificationException should be thrown when new channels become ready while processReadyKeys() is iterating over selector.selectedKeys(). If such an exception is thrown, the test fails, indicating a concurrency flaw in the current implementation.

Key points:

Uses a real selector loop via NioClient.selector(), with no changes to production logic.

Concurrently registers channels and makes them ready using Pipe.sink().write() to trigger select() updates.

Catches ConcurrentModificationException using a custom Thread.UncaughtExceptionHandler.

Includes processing delay to increase overlap and expose the race condition.

| Note: As this is a concurrency test, it may not fail consistently across runs or environments. Flakiness is expected until the underlying issue is fixed.

This test is intended as a reproducible regression check for an existing bug and will serve as a validation gate once a thread-safe fix is applied to processReadyKeys().

@ibauersachs
Copy link
Member

Thanks for the demo. I played around with it, and the only way I can see that the modification of the keys can be triggered outside of the selector thread is by the close() call. This is simple to solve, and I have a PoC for that (wake the selector, run the close tasks from within the selector thread).

Is this the situation you encountered this originally, or is there some other way this can be reproduced without the close() call being involved?

Please also note:

@bhaveshthakker
Copy link
Author

Yes, close() is the only place from issue seems to be reproducible!

Regarding the earlier fix (bhaveshthakker#1): that was created while I was experimenting with the failure, and I ended up pushing it prematurely. It wasn't intended as a finalized PR, so please feel free to disregard it.

Regarding unit test, yes, it was written just to reproduce the issue

Waiting for the solution to come in. LMK if I can be of any help

ibauersachs added a commit that referenced this pull request Jun 14, 2025
Closes #379
Closes #380

Co-authored-by: bhaveshthakker <bhaveshthakker111@gmail.com>
@ibauersachs
Copy link
Member

Does the linked PR #381 work for you?

ibauersachs added a commit that referenced this pull request Jun 21, 2025
Closes #379
Closes #380

Co-authored-by: bhaveshthakker <bhaveshthakker111@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants
0