myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andy Schwartz (JIRA)" <...@myfaces.apache.org>
Subject [jira] [Updated] (TRINIDAD-2468) FileSystemStyleCache: split style sheet concurrency issue
Date Wed, 16 Apr 2014 02:07:14 GMT

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

Andy Schwartz updated TRINIDAD-2468:
------------------------------------

    Status: Patch Available  (was: Open)

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

Mime
View raw message