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