[jira] [Updated] (TRINIDAD-2463) Concurrency issues in CachingResourceLoader

["Andy Schwartz (JIRA)" <de...@myfaces.apache.org>]

     [ https://issues.apache.org/jira/browse/TRINIDAD-2463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andy Schwartz updated TRINIDAD-2463:
------------------------------------

    Status: Patch Available  (was: Open)

> Concurrency issues in CachingResourceLoader
> -------------------------------------------
>
>                 Key: TRINIDAD-2463
>                 URL: https://issues.apache.org/jira/browse/TRINIDAD-2463
>             Project: MyFaces Trinidad
>          Issue Type: Bug
>    Affects Versions: 2.1.0-core
>            Reporter: Andy Schwartz
>            Assignee: Andy Schwartz
>            Priority: Minor
>         Attachments: trinidad-2463.patch
>
>
> I am seeing intermittent failures when serving up skin-generated .css files via the Trinidad ResourceServlet.  When the failure occurs, the ResourceServlet sends a response with conflicting information: the response specifies a Content-Length header that does not match the number of bytes of data that are sent.  In particular, the Content-Length header specifies the correct size of the .css file as it appears on the file system, but the content that is sent back to the browser is truncated.
> Although I haven’t been able to reproduce the problem in a debugger, I suspect that the problem is due to the unsafe way in which CachingResourceLoader.URLStreamHandlerImpl deals with withs cached state.
> One obvious issue with this code is that it is not thread safe.  It performs non-atomic operations (check and set) of the _contents and _contentsModified fields without synchronization (or without any other scheme to ensure thread safety).  Additionally, there is nothing protecting against these fields being modified concurrently.  Also, there is no attempt to ensure that the values assigned to these fields are published safely.
> This is bad.
> Another possible concern is that in theory we could end up reading the .css file contents off of the file system while this file is being written to by a second thread.  In this case, our cached contents may not reflect the full contents of the file as it (eventually) appears on the file system.   However, since we always retrieve the value for the Content-Length response header from the file system, we always send the latest file size, even if this does not match the number of bytes that we have cached.
> This could explain the mismatch that I am seeing between the Content-Length header and the size of our response payload.
> We need to do two things:
> 1.  Make CachingResourceLoader.URLStreamHandlerImpl thread safe.
> 2.  Make CachingResourceLoader more tolerant of content length changes.



--
This message was sent by Atlassian JIRA
(v6.2#6252)