yzeng1618 commented on PR #10131: URL: https://github.com/apache/seatunnel/pull/10131#issuecomment-3605210645
> Hi，I want to know in what scenarios this problem occurs and what the probability of it happening is. The current unit tests may not be able to fully verify it. Thanks for the question. This is not a low‑probability race but a deterministic misuse of wait/notify: whenever the streaming Iceberg enumerator thread reaches stateLock.wait(...) or handleSplitRequest calls stateLock.notifyAll() without holding the stateLock monitor, the JVM will always throw IllegalMonitorStateException according to the Java spec. In practice, the scenario is any unbounded Iceberg job using this enumerator that runs long enough for the enumerator to enter the wait and for readers to call handleSplitRequest after initialization – once that code path is hit, the failure probability is 100%. The new unit test is intentionally minimal: it forces initialized = true via reflection and calls handleSplitRequest(0) to deterministically reproduce the exception before the fix and verify it no longer occurs after the fix. The change in run() uses the same synchronized (stateLock) pattern, so while it’s not covered by a full end‑to‑end streaming test, its correctness follows directly from the Java wait/notify semantics. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
