Details
-
Type:
Bug
-
Status:
Resolved
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 8.1.0
-
Fix Version/s: 8.1.0
-
Component/s: None
-
Labels:None
-
Number of attachments :
Description
We're seeing exceptions like the following:
java.lang.IllegalStateException: STREAM at org.eclipse.jetty.server.Response.getWriter(Response.java:683) ~[jetty-server.jar:8.1.0.RC2]
For any given request/response we either use getOutputStream (if the response is being compressed) or getWriter (if the response is not being compressed). I have done a pretty careful code walk-through to verify this pattern.
We use Continuation and write the response on "our" thread (and thus call Continuation.complete at the end).
My theory about what's going on is that the state in the (per-connection) Response object has data visibility issues.
- A connection (with final Response object R) is used to write a response on "our" thread T1. The output is compressed, so we call getOutputStream, which sets R._outputState to STREAM.
- The response completes, so R.recycle is called (not sure what thread this happens on), which sets R._outputState to NONE, but there is no locking or volatile to make sure that write is published properly.
- Another request comes in on the same connection and
{R}
is used to write the response on "our" thread T2. The response is not compressed so we call getWriter – this is where the exception is thrown.
- The exception is thrown because the write to R._outputState is not visible in T2 so it reads as STREAM.
Am I off in the weeds here?
Anders,
Do you have any code snippets or better yet a small test harness? On the face of it, I don't see that the select key to read any new request would be set before the handling of the previous request/response is done, but your analysis does have some intuitive appeal
Also, if you can get some logs when this happens, with full debug logging turned on, it may be helpful.
thanks
Jan