[
https://issues.apache.org/jira/browse/TRINIDAD-2468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13970674#comment-13970674
]
Andy Schwartz commented on TRINIDAD-2468:
-----------------------------------------
I have put together a patch file that can be applied to trinidad-trunk to help
simulate the problem:
https://issues.apache.org/jira/secure/attachment/12640452/trinidad-2468-hack-delays.patch
This patch does the following:
- Introduces a delay after the first file of a two part style sheet is written.
- Introduces a second delay when a second request detects that a single file is
present on the file system.
- Tweaks our logic for deciding when to split style sheet files to make it
easier to hit the split style sheet file case.
- Adds logging that includes the thread id.
We can now simulate the problem by:
1. Applying the patch to trinidad-trunk.
2. Fire up trinidad-demo
3. Make sure that the trinidad-demo’s style sheet cache is empty.
4. Hit the demo via curl, eg:
curl localhost:8080/trinidad-demo/faces/index.jspx
5. Wait a few seconds, and then hit the demo a second time via curl.
Without the fix, we see the following sequence:
SEVERE: !! Entering _createEntry {thread:12}
SEVERE: !! Got output files: 0 {thread:12}
SEVERE: !! Creating output file:
/scratch/anschwar/dev/trinidad/trinidad-trunk/trinidad-examples/trinidad-demo/target/work/adf/styles/cache/casablanca-desktop-mjyt4t--d-d-d-d-ltr-d--s-n-u.css
{thread:12}
SEVERE: !! I have written one output file. Going to sleep for a while.
{thread:12}
SEVERE: !! Entering _createEntry {thread:16}
SEVERE: !! I found one output file. Going to sleep for a while! {thread:16}
SEVERE: !! Done sleeping. Ready write more output files. {thread:12}
SEVERE: !! Creating output file:
/scratch/anschwar/dev/trinidad/trinidad-trunk/trinidad-examples/trinidad-demo/target/work/adf/styles/cache/casablanca-desktop-mjyt4t--d-d-d-d-ltr-d--s-n-u2.css
{thread:12}
SEVERE: !! Exiting _createEntry. Entry now has 2 file(s) {thread:12}
SEVERE: !! Just one output file here. Waking up. {thread:16}
SEVERE: !! Got output files: 1 {thread:16}
SEVERE: !! Exiting _createEntry. Entry now has 1 file(s) {thread:16}
At this point the entry cache contains an Entry instance with a single file
reference, even though two files were written. All requests from here on out
result in a single style sheet link being rendered.
I have also uploaded a second patch that can be applied on top of my fix
(required some tweaking):
https://issues.apache.org/jira/secure/attachment/12640453/trinidad-2468-hack-delays-on-top-of-fix.patch
When running the same steps against the fix, we now see output like this:
SEVERE: !! Entering _createEntry {thread:12}
SEVERE: !! Got output files: 0 {thread:12}
SEVERE: !! Creating output file:
/scratch/anschwar/dev/trinidad/trinidad-2468-trunk/trinidad-examples/trinidad-demo/target/work/adf/styles/cache/casablanca-desktop-mjyt4t--d-d-d-d-ltr-d--s-n-u.css
{thread:12}
SEVERE: !! I have written one output file. Going to sleep for a while.
{thread:12}
SEVERE: !! Getting entry from Future {thread:16}
SEVERE: !! Done sleeping. Ready write more output files. {thread:12}
SEVERE: !! Creating output file:
/scratch/anschwar/dev/trinidad/trinidad-2468-trunk/trinidad-examples/trinidad-demo/target/work/adf/styles/cache/casablanca-desktop-mjyt4t--d-d-d-d-ltr-d--s-n-u2.css
{thread:12}
SEVERE: !! Exiting _createEntry. Entry now has 2 file(s) {thread:12}
SEVERE: !! Got entry with 2 file(s) from Future {thread:16}
SEVERE: !! Got entry with 2 file(s) from Future {thread:12}
The second thread now waits on Future.get() until the first thread has
completed generating both style sheets. And now everyone has a consistent view
of the world.
> 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.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)
