shiro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Les Hazlewood (JIRA)" <j...@apache.org>
Subject [jira] Issue Comment Edited: (SHIRO-159) ThreadLocal is not cleared upon the unloading of the webapp and the SHiro Servlet
Date Fri, 14 May 2010 05:20:42 GMT

    [ 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.ThreadContext$1@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.


Mime
View raw message