Andy Schwartz created TRINIDAD-2463:
---------------------------------------
Summary: 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
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)
