[jetty-dev] [jira] (JETTY-1475) Data visibility issues in org.eclipse.jetty.server.Response?

     [ https://jira.codehaus.org/browse/JETTY-1475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Bartel resolved JETTY-1475.
-------------------------------

       Resolution: Fixed
    Fix Version/s: 8.1.0

Anders,

This fix went out in the 8.1.0 release. As I haven't heard from you, I assume this is fixed. If not, please reopen this issue and provide as much detail as you can.

thanks
Jan
                
> Data visibility issues in org.eclipse.jetty.server.Response?
> ------------------------------------------------------------
>
>                 Key: JETTY-1475
>                 URL: https://jira.codehaus.org/browse/JETTY-1475
>             Project: Jetty
>          Issue Type: Bug
>    Affects Versions: 8.1.0
>            Reporter: Anders Wallgren
>            Assignee: Jan Bartel
>             Fix For: 8.1.0
>
>
> We're seeing exceptions like the following:
> {code}
> java.lang.IllegalStateException: STREAM
> 	at org.eclipse.jetty.server.Response.getWriter(Response.java:683) ~[jetty-server.jar:8.1.0.RC2]
> {code}
> 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?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email