myfaces-dev mailing list archives

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


Andy Schwartz commented on TRINIDAD-2468:

The provided patch:

Fixes the thread safety issues by converting the FileSystemStyleCache's entry cache over to
the "efficient, scalable result cache" solution described in JCIP section 5.6.  This solution
uses Future instances as cache entries to constrain access to each entry value.  The first
request into the cache for a particular key puts a Future instance into the cache and then
kicks off the computation of the Future's value.  (In FileSystemStyleCache's case, this includes
generating the files corresponding to the cache entry.)  Each subsequent cache access is routed
through a call to Future.get(), which will block until the Future's value is computed.

Requests for other cache entries can happily proceed in parallel.  As a result, we get thread-safety
on a per-entry basis with no loss of concurrency across entries.

> FileSystemStyleCache: split style sheet concurrency issue
> ---------------------------------------------------------
>                 Key: TRINIDAD-2468
>                 URL:
>             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:
> 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
> 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
> - 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

View raw message