struts-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Don Brown (JIRA)" <j...@apache.org>
Subject [jira] Resolved: (WW-1544) Dispatcher threadlocal cleanup does not clean up the threadlocal
Date Fri, 08 Dec 2006 20:56:57 GMT
     [ http://issues.apache.org/struts/browse/WW-1544?page=all ]

Don Brown resolved WW-1544.
---------------------------

    Resolution: Fixed

The dispatcher should now be cleaned up after every request.  Furthermore, I tied the objectfactory
instance to the dispatcher so that each dispatcher could have its own objectfactory configuration.
 I also ensured the portlet dispatcher properly cleaned the dispatcher instance from the thread
on every request.  If you see anything I missed, please reopen the ticket.

> Dispatcher threadlocal cleanup does not clean up the threadlocal
> ----------------------------------------------------------------
>
>                 Key: WW-1544
>                 URL: http://issues.apache.org/struts/browse/WW-1544
>             Project: Struts 2
>          Issue Type: Bug
>    Affects Versions: 2.0.1
>            Reporter: Rickard Öberg
>         Assigned To: Don Brown
>             Fix For: 2.0.2
>
>
> In Dispatcher.cleanup() there is supposedly code to do (as the JavaDoc states) "Cleans
up thread local variables". 
> However, the actual codes does "instance.set(null);" which is not a threadlocal cleanup.
It only sets the reference of the current thread to null, meaning, there may be a bunch of
other threads with references to Dispatchers. 
> The proper way to clean up a threadlocal is to set it to null, i.e. "instance = null".
> However, it appears that this breaks pretty much all tests. The basic usage of how Dispatchers
are used is, it seems, messed up. If it is supposed to be some local context only, then it
should be set and cleared immediately, e.g. in FilterDispatcher.doFilter(), instead of leaving
Dispatcher references hanging possibly indefinitely.
> Apart from fixing this I would suggest that the way these instances are managed should
be rethought. If, for example, both FilterDispatcher and Jsr168Dispatcher are used (as we
do), then (if Jsr168Dispatcher also does Dispatcher.cleanup, as it should) there will be many
calls to cleanup() and hence possibly many ObjectFactory.destroy() and dispatcherListener.dispatcherDestroyed()
calls. It appears that Dispatcher is a bit schizophrenic with regard to who owns and manages
it.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

Mime
View raw message