You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@shiro.apache.org by jeffp <je...@gmail.com> on 2012/10/30 19:41:38 UTC
unclean shutdown of Tomcat
Upon shutdown of my Tomcat instance I'm seeing hundreds of the message below
in my log. The reason for shutdown was that upon authentication Tomcat
never returns a response (after working nicely for several days).
Unauthenticated URL's were returning fine. I'm running on Shiro 1.1.
I think this is related to https://issues.apache.org/jira/browse/SHIRO-159,
but I'm not exactly sure. My config is using a Spring
DelegatingFilterProxy and the ShiroFilterFactoryBean.
QUESTIONS
1. I've found Controllers that are calling SecurityUtils.getSubject() while
being mapped to /** = anon. Does this result in uncleaned ThreadLocal's as
per the bug above?
2. Are URL's mapped to /** = anon under the control of the ShiroFilter?
web.xml:
<filter>
<filter-name>shiroFilter</filter-name>
<filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
<init-param>
<param-name>targetFilterLifecycle</param-name>
<param-value>true</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>shiroFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
applicationContext.xml:
<bean id="shiroFilter"
class="org.apache.shiro.spring.web.ShiroFilterFactoryBean">
<property name="securityManager" ref="securityManager"/>
<property name="loginUrl" value="/login.do"/>
<property name="unauthorizedUrl" value="/home/noaccess.do"/>
<property name="successUrl" value="/sm/index.do"/>
<property name="filterChainDefinitions">
<value>
/login.do = authc
/sm/admin/** = authc, roles[unit-admin]
/sm/** = authc
/** = anon
</value>
</property>
</bean>
TOMCAT SHUTDOWN MESSAGE
Oct 30, 2012 2:05:22 AM org.apache.catalina.loader.WebappClassLoader
clearThreadLocalMap
SEVERE: The web application [] created a ThreadLocal with key of type
[org.apache.shiro.util.ThreadContext.InheritableThreadLocalMap] (value
[org.apache.shiro.util.ThreadContext$InheritableThreadLocalMap@29593df4])
and a value of type [java.util.HashMap] (value
[{org.apache.shiro.util.ThreadContext_SUBJECT_KEY=org.apache.shiro.web.subject.support.WebDelegatingSubject@7b2ac98d,
org.apache.shiro.util.ThreadContext_SECURITY_MANAGER_KEY=org.apache.shiro.web.mgt.DefaultWebSecurityManager@3474f6b0}])
but failed to remove it when the web application was stopped. This is very
likely to create a memory leak.
--
View this message in context: http://shiro-user.582556.n2.nabble.com/unclean-shutdown-of-Tomcat-tp7577893.html
Sent from the Shiro User mailing list archive at Nabble.com.
Re: unclean shutdown of Tomcat
Posted by Les Hazlewood <lh...@apache.org>.
Glad it worked out!
--
Les Hazlewood | @lhazlewood
CTO, Stormpath | http://stormpath.com | @goStormpath | 888.391.5282
Stormpath wins GigaOM Structure Launchpad Award! http://bit.ly/MvZkMk
On Tue, Nov 6, 2012 at 1:07 PM, jeffp <je...@gmail.com> wrote:
> OK, mystery solved. Sorry its taken me a bit of time to get back to
> responding.
>
> The problem was a bad data access configuration that left a database
> connection open. When the pool eventually ran out of connections, the
> sessions began to stack up and wait -- which were tied to the Shiro
> ThreadLocal. This caused the application to "stop functioning" so when we
> bounced Tomcat the messages came flowing out.
>
> Now that the connections are going back to the pool, we're clean on
> shutdown. Thanks Les!
>
>
>
> --
> View this message in context:
> http://shiro-user.582556.n2.nabble.com/unclean-shutdown-of-Tomcat-tp7577893p7577912.html
> Sent from the Shiro User mailing list archive at Nabble.com.
>
Re: unclean shutdown of Tomcat
Posted by jeffp <je...@gmail.com>.
OK, mystery solved. Sorry its taken me a bit of time to get back to
responding.
The problem was a bad data access configuration that left a database
connection open. When the pool eventually ran out of connections, the
sessions began to stack up and wait -- which were tied to the Shiro
ThreadLocal. This caused the application to "stop functioning" so when we
bounced Tomcat the messages came flowing out.
Now that the connections are going back to the pool, we're clean on
shutdown. Thanks Les!
--
View this message in context: http://shiro-user.582556.n2.nabble.com/unclean-shutdown-of-Tomcat-tp7577893p7577912.html
Sent from the Shiro User mailing list archive at Nabble.com.
Re: unclean shutdown of Tomcat
Posted by Les Hazlewood <lh...@apache.org>.
Also, what version of Tomcat are you running? 7.0.6 and later will
auto-cleanup some classloader-related leaks.
On Tue, Oct 30, 2012 at 6:35 PM, Les Hazlewood <lh...@apache.org> wrote:
> Hi Jeff,
>
> Shiro will automatically clean up its thread context at the end of a
> request. It does this using a SubjectCallable and ThreadState
> mechanism:
>
> http://shiro.apache.org/static/current/xref/org/apache/shiro/subject/support/SubjectCallable.html#81
>
> the finally block will restore any previous thread state. If there
> wasn't any previous thread state, ThreadContext.remove() is called,
> which completely removes the ThreadLocal entirely.
>
> Because this is done in a finally block, it is auto-cleaned at the end
> of a request. The Shiro Filter calls subject.execute() to execute the
> request to ensure that the SubjectCallable/ThreadState cleanup happens
> automatically. i.e. subject.execute -> creates a SubjectCallable -->
> subjectCallable.call() --> finally { threadState.restore(); }
>
> Do you have any threads in your application that use Shiro that are
> _not_ initiated by a web request? I.e. maybe a daemon or async
> thread? If so, you will need to ensure that you perform the same
> cleanup (or use Subject.execute to automate this cleanup) to ensure
> the thread is 'clean' before being reused.
>
> Also, do you start/stop the web application often while the servlet
> container is running? If so, that could create separate class
> loaders, and each class loader would create its own ThreadContext
> class and then threadlocal instance:
> http://wiki.apache.org/tomcat/MemoryLeakProtection
>
> I'm not sure what else could be causing these messages for you given
> Shiro's auto-cleanup mechanism, but we're open to details and/or test
> cases or sample apps that demonstrate a problem!!!
>
> Best,
>
> --
> Les Hazlewood | @lhazlewood
> CTO, Stormpath | http://stormpath.com | @goStormpath | 888.391.5282
> Stormpath wins GigaOM Structure Launchpad Award! http://bit.ly/MvZkMk
>
> On Tue, Oct 30, 2012 at 11:41 AM, jeffp <je...@gmail.com> wrote:
>>
>> Upon shutdown of my Tomcat instance I'm seeing hundreds of the message below
>> in my log. The reason for shutdown was that upon authentication Tomcat
>> never returns a response (after working nicely for several days).
>> Unauthenticated URL's were returning fine. I'm running on Shiro 1.1.
>>
>> I think this is related to https://issues.apache.org/jira/browse/SHIRO-159,
>> but I'm not exactly sure. My config is using a Spring
>> DelegatingFilterProxy and the ShiroFilterFactoryBean.
>>
>> QUESTIONS
>> 1. I've found Controllers that are calling SecurityUtils.getSubject() while
>> being mapped to /** = anon. Does this result in uncleaned ThreadLocal's as
>> per the bug above?
>>
>> 2. Are URL's mapped to /** = anon under the control of the ShiroFilter?
>>
>> web.xml:
>> <filter>
>> <filter-name>shiroFilter</filter-name>
>>
>> <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
>> <init-param>
>> <param-name>targetFilterLifecycle</param-name>
>> <param-value>true</param-value>
>> </init-param>
>> </filter>
>>
>> <filter-mapping>
>> <filter-name>shiroFilter</filter-name>
>> <url-pattern>/*</url-pattern>
>> </filter-mapping>
>>
>> applicationContext.xml:
>> <bean id="shiroFilter"
>> class="org.apache.shiro.spring.web.ShiroFilterFactoryBean">
>> <property name="securityManager" ref="securityManager"/>
>> <property name="loginUrl" value="/login.do"/>
>> <property name="unauthorizedUrl" value="/home/noaccess.do"/>
>> <property name="successUrl" value="/sm/index.do"/>
>> <property name="filterChainDefinitions">
>> <value>
>> /login.do = authc
>> /sm/admin/** = authc, roles[unit-admin]
>> /sm/** = authc
>> /** = anon
>> </value>
>> </property>
>> </bean>
>>
>> TOMCAT SHUTDOWN MESSAGE
>> Oct 30, 2012 2:05:22 AM org.apache.catalina.loader.WebappClassLoader
>> clearThreadLocalMap
>> SEVERE: The web application [] created a ThreadLocal with key of type
>> [org.apache.shiro.util.ThreadContext.InheritableThreadLocalMap] (value
>> [org.apache.shiro.util.ThreadContext$InheritableThreadLocalMap@29593df4])
>> and a value of type [java.util.HashMap] (value
>> [{org.apache.shiro.util.ThreadContext_SUBJECT_KEY=org.apache.shiro.web.subject.support.WebDelegatingSubject@7b2ac98d,
>> org.apache.shiro.util.ThreadContext_SECURITY_MANAGER_KEY=org.apache.shiro.web.mgt.DefaultWebSecurityManager@3474f6b0}])
>> but failed to remove it when the web application was stopped. This is very
>> likely to create a memory leak.
>>
>>
>>
>> --
>> View this message in context: http://shiro-user.582556.n2.nabble.com/unclean-shutdown-of-Tomcat-tp7577893.html
>> Sent from the Shiro User mailing list archive at Nabble.com.
Re: unclean shutdown of Tomcat
Posted by Les Hazlewood <lh...@apache.org>.
Hi Jeff,
Shiro will automatically clean up its thread context at the end of a
request. It does this using a SubjectCallable and ThreadState
mechanism:
http://shiro.apache.org/static/current/xref/org/apache/shiro/subject/support/SubjectCallable.html#81
the finally block will restore any previous thread state. If there
wasn't any previous thread state, ThreadContext.remove() is called,
which completely removes the ThreadLocal entirely.
Because this is done in a finally block, it is auto-cleaned at the end
of a request. The Shiro Filter calls subject.execute() to execute the
request to ensure that the SubjectCallable/ThreadState cleanup happens
automatically. i.e. subject.execute -> creates a SubjectCallable -->
subjectCallable.call() --> finally { threadState.restore(); }
Do you have any threads in your application that use Shiro that are
_not_ initiated by a web request? I.e. maybe a daemon or async
thread? If so, you will need to ensure that you perform the same
cleanup (or use Subject.execute to automate this cleanup) to ensure
the thread is 'clean' before being reused.
Also, do you start/stop the web application often while the servlet
container is running? If so, that could create separate class
loaders, and each class loader would create its own ThreadContext
class and then threadlocal instance:
http://wiki.apache.org/tomcat/MemoryLeakProtection
I'm not sure what else could be causing these messages for you given
Shiro's auto-cleanup mechanism, but we're open to details and/or test
cases or sample apps that demonstrate a problem!!!
Best,
--
Les Hazlewood | @lhazlewood
CTO, Stormpath | http://stormpath.com | @goStormpath | 888.391.5282
Stormpath wins GigaOM Structure Launchpad Award! http://bit.ly/MvZkMk
On Tue, Oct 30, 2012 at 11:41 AM, jeffp <je...@gmail.com> wrote:
>
> Upon shutdown of my Tomcat instance I'm seeing hundreds of the message below
> in my log. The reason for shutdown was that upon authentication Tomcat
> never returns a response (after working nicely for several days).
> Unauthenticated URL's were returning fine. I'm running on Shiro 1.1.
>
> I think this is related to https://issues.apache.org/jira/browse/SHIRO-159,
> but I'm not exactly sure. My config is using a Spring
> DelegatingFilterProxy and the ShiroFilterFactoryBean.
>
> QUESTIONS
> 1. I've found Controllers that are calling SecurityUtils.getSubject() while
> being mapped to /** = anon. Does this result in uncleaned ThreadLocal's as
> per the bug above?
>
> 2. Are URL's mapped to /** = anon under the control of the ShiroFilter?
>
> web.xml:
> <filter>
> <filter-name>shiroFilter</filter-name>
>
> <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
> <init-param>
> <param-name>targetFilterLifecycle</param-name>
> <param-value>true</param-value>
> </init-param>
> </filter>
>
> <filter-mapping>
> <filter-name>shiroFilter</filter-name>
> <url-pattern>/*</url-pattern>
> </filter-mapping>
>
> applicationContext.xml:
> <bean id="shiroFilter"
> class="org.apache.shiro.spring.web.ShiroFilterFactoryBean">
> <property name="securityManager" ref="securityManager"/>
> <property name="loginUrl" value="/login.do"/>
> <property name="unauthorizedUrl" value="/home/noaccess.do"/>
> <property name="successUrl" value="/sm/index.do"/>
> <property name="filterChainDefinitions">
> <value>
> /login.do = authc
> /sm/admin/** = authc, roles[unit-admin]
> /sm/** = authc
> /** = anon
> </value>
> </property>
> </bean>
>
> TOMCAT SHUTDOWN MESSAGE
> Oct 30, 2012 2:05:22 AM org.apache.catalina.loader.WebappClassLoader
> clearThreadLocalMap
> SEVERE: The web application [] created a ThreadLocal with key of type
> [org.apache.shiro.util.ThreadContext.InheritableThreadLocalMap] (value
> [org.apache.shiro.util.ThreadContext$InheritableThreadLocalMap@29593df4])
> and a value of type [java.util.HashMap] (value
> [{org.apache.shiro.util.ThreadContext_SUBJECT_KEY=org.apache.shiro.web.subject.support.WebDelegatingSubject@7b2ac98d,
> org.apache.shiro.util.ThreadContext_SECURITY_MANAGER_KEY=org.apache.shiro.web.mgt.DefaultWebSecurityManager@3474f6b0}])
> but failed to remove it when the web application was stopped. This is very
> likely to create a memory leak.
>
>
>
> --
> View this message in context: http://shiro-user.582556.n2.nabble.com/unclean-shutdown-of-Tomcat-tp7577893.html
> Sent from the Shiro User mailing list archive at Nabble.com.