Affects Version/s: 8.1.0
Fix Version/s: 8.1.0
Number of attachments :
We're seeing exceptions like the following:
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
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?