[
https://issues.apache.org/jira/browse/TRINIDAD-2468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13998869#comment-13998869
]
Andy Schwartz commented on TRINIDAD-2468:
-----------------------------------------
This is a new version of the fix:
https://issues.apache.org/jira/secure/attachment/12645030/trinidad-2468-take3.patch
That modifies the case where FileSystemStyleCache._createEntry() fails because
there are no matching style nodes found.
Before my fix, this failed silently.
In the first two versions of my fix, this fails with a NullPointerException.
After discussing with Blake, we decided that it is best to make this case fail
in a more obvious way. This now fails with an IllegalStateException with a
more useful error message.
> FileSystemStyleCache: split style sheet concurrency issue
> ---------------------------------------------------------
>
> Key: TRINIDAD-2468
> URL: https://issues.apache.org/jira/browse/TRINIDAD-2468
> Project: MyFaces Trinidad
> Issue Type: Bug
> Components: Skinning
> Reporter: Andy Schwartz
> Assignee: Andy Schwartz
> Attachments: trinidad-2468-hack-delays-on-top-of-fix.patch,
> trinidad-2468-hack-delays.patch, trinidad-2468-take2.patch,
> trinidad-2468-take3.patch, trinidad-2468.patch
>
>
> Due to IE’s per-file style rule limit, documented here:
>
> http://support.microsoft.com/kb/262161
> In particular:
> “All style rules after the first 4,095 rules are not applied.”
> Trinidad’s skinning framework breaks up large style sheets into multiple
> files, each with a maximum of 4,095 rules. That is, a generated style sheet
> of the form:
> - foo-desktop-gecko.css
> Might be result in the generation of two style sheets on IE:
> - foo-desktop-ie.css
> - foo-desktop-ie2.css
> We are running into thread safety problems with the current implementation of
> this multi-file solution.
> Under certain circumstances, we see the style sheet (correctly) being split
> across two files, but only a single style sheet link is rendered in the HTML
> contents. As a result, the styles from the second file are missing, which
> typically has fatal results.
> This only happens under a somewhat unusual case: the client who is reporting
> this behavior is running a test which upon start up immediately hits the
> server with two concurrent requests from IE.
> This triggers the following sequence:
> - Request 1 enters FileSystemStyleCache._createEntry().
> - Request 1 generates the first of two files that make up the IE-specific
> style sheet.
> - Request 2 arrives and, finding FileSystemStyleCache’s entry cache empty,
> also enters _createEntry().
> - Upon entry to _createEntry(), Request 2 checks to see whether any files
> have already been generated for the requested style sheet.
> - Request 2 finds the first of two files and assumes that the style sheet is
> composed of a single file.
> - Request 1 finishes generating the second style sheet.
> - Request 1 populates the FileSystemStyleCache’s entry cache with an Entry
> instance that correctly references both generated files.
> - Request 2 blows away the previously installed Entry and replaces it with a
> bogus Entry that only references the first of two style sheet files.
> On all subsequent requests, StyleSheetRenderer retrieves data from the bogus
> (single file) Entry, and thus only renders a single link.
> The fix is to control access to _createEntry() for individual style sheets.
> That is, we want to allow concurrent access to _createEntry() for style
> sheets with different variants (ie. it should be possible to generate the IE
> style sheets and Gecko style sheets concurrently). However, if a request is
> in the middle of generating files for a particular style sheet, other
> requests that want access to the same style sheet must wait until the first
> request completes its work (instead of possibly trampling over the work of
> the first request).
--
This message was sent by Atlassian JIRA
(v6.2#6252)
