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 <[email protected]> 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.
