[
https://issues.apache.org/jira/browse/SHIRO-159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12867395#action_12867395
]
Les Hazlewood edited comment on SHIRO-159 at 5/14/10 1:19 AM:
--------------------------------------------------------------
I'm not sure of what to do about the getSubject() call - all the other areas in
the framework are covered from a responsibility perspective I think:
- The AbstractShiroFilter binds and unbinds for an incoming request
- The Spring RemoteInvocationExecutor binds and unbinds for an incoming remote
method invocation
- The Executor/ExecutorService/ScheduledExecutorService implementations
bind/unbind for async/'other thread' execution.
- Subject.associateWith* guarantees cleanup
- Subject.execute* guarantees cleanup
The getSubject() auto-creation is the only area where we can't guarantee
cleanup. But the idea is if you call that method in the course of execution
with any of the above 5 mechanisms, then everything should be ok. I don't know
of any other way to guarantee cleanup. Even a ContextListener probably
wouldn't do the job - you'd only be able to clear the thread that calls the
listener - not any of the other threads that are in the request thread pool.
was (Author: lhazlewood):
I'm not sure of what to do about the getSubject() call - all the other
areas in the framework are covered from a responsibility perspective I think:
- The AbstractShiroFilter binds and unbinds for an incoming request
- The Spring RemoteInvocationExecutor binds and unbinds for an incoming remote
method invocation
- The Executor/ExecutorService/ScheduledExecutorService implementations
bind/unbind for async/'other thread' execution.
The getSubject() auto-creation is the only area where we can't guarantee
cleanup. But the idea is if you call that method in the course of execution
with any of the above 3 methods, then everything should be ok. I don't know of
any other way to guarantee cleanup. Even a ContextListener probably wouldn't
do the job - you'd only be able to clear the thread that calls the listener -
not any of the other threads that are in the request thread pool.
> ThreadLocal is not cleared upon the unloading of the webapp and the SHiro
> Servlet
> ---------------------------------------------------------------------------------
>
> Key: SHIRO-159
> URL: https://issues.apache.org/jira/browse/SHIRO-159
> Project: Shiro
> Issue Type: Bug
> Components: Integration: JEE
> Affects Versions: 1.0.0
> Environment: Model Name: MacBook Pro
> Model Identifier: MacBookPro5,1
> Processor Name: Intel Core 2 Duo
> Processor Speed: 2.8 GHz
> Number Of Processors: 1
> Total Number Of Cores: 2
> L2 Cache: 6 MB
> Memory: 4 GB
> Bus Speed: 1.07 GHz
> System Version: Mac OS X 10.6.3 (10D573)
> Kernel Version: Darwin 10.3.0
>
> Reporter: david e. berry
> Fix For: 1.0.0
>
>
> Tomcat 6.0.26 reports a severe error when unloading a web app that uses
> org.apache.shiro.web.servlet.IniShiroFilter
> SEVERE: A web application created a ThreadLocal with key of type [null]
> (value [org.apache.shiro.util.threadcontex...@c0c66a]) and a value of type
> [java.util.HashMap] (value [{}]) but failed to remove it when the web
> application was stopped. To prevent a memory leak, the ThreadLocal has been
> forcibly removed.
> May 13, 2010 9:29:51 PM org.apache.catalina.loader.WebappClassLoader
> clearThreadLocalMap
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
