-
Notifications
You must be signed in to change notification settings - Fork 2k
Race Condition in WebSocketConnection - Job failed: java.lang.IllegalStateException: FILLING_AND_PARSING #13299
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
Race Condition in WebSocketConnection - Job failed: java.lang.IllegalStateException: FILLING_AND_PARSING #13299
Conversation
Signed-off-by: Lachlan Roberts <lachlan.p.roberts@gmail.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@lachlan-roberts This failure looks like more than a flake:
2025-06-29 20:48:43.421:WARN :oejuts.AdaptiveExecutionStrategy:WebSocket@2039328294-4500: Task run failed
java.lang.IllegalStateException: FILLING_AND_PARSING
at org.eclipse.jetty.websocket.core.WebSocketConnection.fillAndParse(WebSocketConnection.java:480)
at org.eclipse.jetty.websocket.core.WebSocketConnection.onFillable(WebSocketConnection.java:372)
at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:322)
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:99)
at org.eclipse.jetty.io.SelectableChannelEndPoint$1.run(SelectableChannelEndPoint.java:53)
at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.runTask(AdaptiveExecutionStrategy.java:480)
at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.consumeTask(AdaptiveExecutionStrategy.java:443)
at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.tryProduce(AdaptiveExecutionStrategy.java:293)
at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.run(AdaptiveExecutionStrategy.java:201)
at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:311)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:981)
at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.doRunJob(QueuedThreadPool.java:1211)
at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1166)
at java.base/java.lang.Thread.run(Thread.java:1583)
…g state Signed-off-by: Lachlan Roberts <lachlan.p.roberts@gmail.com>
@gregw I cannot see that failure in the CI results. But that would indicate an issue with the original PR #13264 not with this one. It is because we are registering as So I have added another commit to this PR to fix this. |
@lachlan-roberts this missed the 12.0.23 release. |
@joakime the issue is a race condition, so the tests just got lucky and didn't trigger it. I really don't think we should release 12.0.23 without this fix. |
There is no test case for this supposed race condition. |
I've been able to confirm that the mentioned stacktrace exists in the
|
Signed-off-by: Lachlan Roberts <lachlan.p.roberts@gmail.com>
Stack is still present in JDK17 build. https://jenkins.webtide.net/blue/organizations/jenkins/jetty.project/detail/PR-13299/4/pipeline/12
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good. But see comment about an enhancement for another PR
networkBuffer.release(); | ||
networkBuffer = newNetworkBuffer(getInputBufferSize()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@lachlan-roberts not for this PR, but we should do the same as HTTP/1 and reuse the existing buffer, even if retained, if there is sufficient space in it to do something useful. See org.eclipse.jetty.server.internal.HttpConnection#parseAndFillForContent
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Race condition still present when demand()
is called from application code, and the parser thread has not hit the finally
block in filllAndParse()
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@lachlan-roberts, Simone briefed me on the remaining race condition. I will look today. Ping me if you are online at all
This resolves the race between one thread asking for more f&p and another exiting the state. Will investigate an alternative using ICB now.
This resolves the race between one thread asking for more f&p and another exiting the state. Will investigate an alternative using ICB now.
@lachlan-roberts @sbordet I tried converting the fillAndParse into an IteratingCallback. It was surprisingly mostly successful, and most of the tests pass. But then a few tests fail in strange ways (missing bytes from the middle of message etc), so it is not as simple as it looks. I think replacing executes with iterates is a big change in the threading model and we should not consider it for this release cycle. Instead I think the fix as it is now should go to the release and @lachlan-roberts can look at making it an ICB after. |
Signed-off-by: Lachlan Roberts <lachlan.p.roberts@gmail.com>
Signed-off-by: Lachlan Roberts <lachlan.p.roberts@gmail.com>
If the build is green, and you are happy with these changes, do merge this. |
@gregw I think Lachlan will need and approval to merge |
After PR #13264 there is a new race condition that can prevent a
WebSocketConnection
from completing.This stacktrace can be seen in
jetty-12.0.x
HEAD on build job for JDK17 and JDK21 (doesn't happen in JDK24) -