You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by "Stephen Colebourne (JIRA)" <ji...@apache.org> on 2006/12/29 14:12:27 UTC
[jira] Resolved: (IO-99) FileCleaner thread never ends and cause
memory leak in AS
[ http://issues.apache.org/jira/browse/IO-99?page=all ]
Stephen Colebourne resolved IO-99.
----------------------------------
Resolution: Fixed
Assignee: Stephen Colebourne
I took a look at getTrackerCount(), but its already synchronized because the list is a Vector. I added a few comments about synchronization to the file to help clarify.
Closing the call as fixed.
> FileCleaner thread never ends and cause memory leak in AS
> ---------------------------------------------------------
>
> Key: IO-99
> URL: http://issues.apache.org/jira/browse/IO-99
> Project: Commons IO
> Issue Type: Bug
> Affects Versions: 1.2
> Environment: JBOssPortal with commons.fileupload
> Reporter: Vera Mickaël
> Assigned To: Stephen Colebourne
> Priority: Critical
> Fix For: 1.3
>
> Attachments: IO-99.patch
>
>
> FileCleaner opens a thread and no solution is given to the user to end it. So when an application is undeployed
> in an Application Server, a thread is still alive. The WebApp can't be undeployed and this results in a classloader
> leak that will cause an OutOfMemoryError.
> I think the API should be extended so that a user can end the thread. A better way would be to provide a class that
> cleans everything for commons IO.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org