Fix stopDispatcherThreads() to block until dispatcher threads have actually terminated

[Copilot]

• Understand the issue: stopDispatcher() sets stopped = true immediately, making the wait loop exit before the dispatcher thread actually finishes
• Remove premature stopped = true from stopDispatcher() so isStopped() reflects real termination
• Add thread-tracking join mechanism to ThreadAdapter: capture runnerThread in run(), signal startedLatch, then awaitTermination() calls Thread.join() — guarantees isAlive() == false on return (fixes Windows/JDK21 race)
• Update stopDispatcherThreads() to snapshot dispatchers (not use live view) and use awaitTermination() instead of polling isStopped()
• Add regression test testStopDispatcherThreadsIsBlocking: enqueue slow-processing message, call stop, assert thread is dead immediately after stop returns (no polling needed)
• All 7 tests pass

Original prompt

Create a fix for issue #1128 so that when stop() returns, the ThreadPerSessionEventHandlingStrategy message dispatcher threads are actually stopped (no further message processing occurs).

Constraints / requirements:

• Open a PR against the master branch.
• Do NOT change behavior such that END_OF_STREAM is prevented from being delivered to quickfixSession.next(); keep the existing semantics where the END_OF_STREAM message is passed to quickfixSession.next(message).

Observed bug:

• ThreadPerSessionEventHandlingStrategy.stopDispatcherThreads() attempts to wait for dispatchers to stop by polling MessageDispatchingThread::isStopped.
• MessageDispatchingThread.stopDispatcher() currently sets stopping = true and stopped = true immediately after enqueuing END_OF_STREAM, so isStopped() can return true before the dispatcher thread has actually terminated.
• This makes stop() effectively non-blocking with respect to message processing: messages may continue to be processed after stop() returns.

Implementation goals:

1. Ensure stopDispatcherThreads() blocks until each dispatcher thread has completed its doRun() (or until a reasonable timeout, if needed).
2. Make isStopped() reflect real termination rather than a stop request.
3. Avoid iterating on a live view of dispatchers.values() in a way that can cause concurrent modification surprises; snapshot dispatchers to stop.
4. Provide a join/await mechanism for ThreadPerSessionEventHandlingStrategy.ThreadAdapter so callers can wait for thread completion even when backed by an Executor.
5. Add or update tests to reliably reproduce the issue (e.g., enqueue messages and slow processing, call stop, assert no more processing happens after stop returns; also assert QF/J dispatcher threads are gone).

Likely files:

• quickfixj-core/src/main/java/quickfix/mina/ThreadPerSessionEventHandlingStrategy.java
• quickfixj-core/src/test/java/... (add/modify tests for thread-per-session stop behavior)

Acceptance criteria:

• After stopDispatcherThreads() returns (and therefore after stop() which invokes it), no dispatcher threads continue to process messages.
• Tests pass and cover the regression.

This pull request was created from Copilot chat.

---

🔒 GitHub Advanced Security automatically protects Copilot coding agent pull requests. You can protect all pull requests by enabling Advanced Security for your repositories. Learn more about Advanced Security.

[chrjohn]

@copilot the test fails on windows with jdk21, but probably it is a general problem

ThreadPerSessionEventHandlingStrategyTest.testStopDispatcherThreadsIsBlocking:374 Dispatcher thread must be dead after stopDispatcherThreads() returns

[Copilot]

@copilot the test fails on windows with jdk21, but probably it is a general problem

ThreadPerSessionEventHandlingStrategyTest.testStopDispatcherThreadsIsBlocking:374 Dispatcher...

Fixed in dcf45b2. The root cause was a race between CountDownLatch.countDown() (which fired in the finally block of run()) and Thread.isAlive() transitioning to false — on Windows/JDK21 that gap was observable.

Replaced the done-latch with thread tracking + Thread.join():

• run() now captures runnerThread = Thread.currentThread() and counts down a startedLatch before doing any work
• awaitTermination() first awaits the startedLatch (handles the case where it's called before the thread even starts), then calls runnerThread.join(remaining) — which by JVM spec guarantees isAlive() == false when it returns