[
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)
