[jira] Commented: (TRINIDAD-1273) Apply a request lifecuycle to ThreadLocals so that their contents don't leak across requests

["Blake Sullivan (JIRA)" <de...@myfaces.apache.org>]

    [ https://issues.apache.org/jira/browse/TRINIDAD-1273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12641148#action_12641148 ] 

Blake Sullivan commented on TRINIDAD-1273:
------------------------------------------

I forgot to mention that these ThreadLocals cause problems because the code using the ThreadLocal typically doesn't know enough about the request lifecycle to know when it can safely remove the ThreadLocal.  As a result, the ThreadLocal for this thread still exists when the request completes.  If the Servlet Container doesn't clean up all of the thread's ThreadLocals before returning the ThreadLocal to the thread pool, we have the following bad cases:
1) ThreadLocal content leaks until this thread happens to be reassigned to a request that uses the ThreadLocals at which point it might still leak
2) Application assumes that a non-null ThreadLocal has been initialized by this request and thus reads stale data
3) The ServletContainer supports hot patching of application content.  If the application is patched and a ThreadLocal references classes in the application's classloader, the entire old classloader will leak and references to the old class instances from the new classloader will cause class cast exceptions.


> Apply a request lifecuycle to ThreadLocals so that their contents don't leak across requests
> --------------------------------------------------------------------------------------------
>
>                 Key: TRINIDAD-1273
>                 URL: https://issues.apache.org/jira/browse/TRINIDAD-1273
>             Project: MyFaces Trinidad
>          Issue Type: Improvement
>          Components: Archetype
>    Affects Versions: 1.0.9-core, 1.2.9-core
>         Environment: All Web Servers that use thread pools and do not clean up ThreadLocals before returning the threads to the pool.  This includes at least WLS and OC4J
>            Reporter: Blake Sullivan
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> Trinidad and Trinidad customers use ThreadLocals to track per-request state in several instances.  Typically, a ThreadLocal is used because the consuming code does not have access to the Request Object.  Even though, the Request Object is available off of the ExternalContext, code that executes extremely early or late in the request lifecycle may not have access to a FacesContext.
> The proposed solution is to add a org.apache.myfaces.trinidad.util.ThreadLocalUtils class with a method:
>   public static <T> ThreadLocal<T> newRequestThreadLocal()
> That will create a ThreadLocal instance that will be reset by the Trinidad implementation when the request finishes (using the same hook point that the Trinidad RequestContext uses to clean itself up).  The trickiest part of the implementation is connecting the code that causes the removal of the ThreadLocals (which exists in the impl package) with the code that creates the ThreadLocals to be reset, which exists in the api package.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.