commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vera Mickaël (JIRA) <>
Subject [jira] Commented: (IO-99) FileCleaner thread never ends and cause memory leak in AS
Date Mon, 20 Nov 2006 17:34:04 GMT
    [ ] 
Vera Mickaël commented on IO-99:

Thanks everybody for your interest in this issue.

I've talked about this issue with a developper mastering classloaders problems. It seems that
the remaining thread surely causes a classoder leak. I think classloaders leaks will soon
be a point of interest for a larger community, this issue will be benefic for

I think is that backward compatibility is important and that you should keep the thread automatically

Be carrefull of several points about web containers environements :

If the lib is deployed for any reason (this is not encouraged) in the classloader of the web
container, the thread is shared by all applications deployed in the container. So an application
stopping the thread would have an effect on other applications. Keeping all applications deployed
isolated is very important. 

But shall we let responsability to developpers to know if they have to stop the thread or
not ? I don't think so. I can develop a lib that uses and I want my lib to be compatible
with web containers environement, as commons.filepload for example. commons.filepload don't
know if has to stop the thread or not because it doesn't know where the lib has
been deployed. But commons.fileupload in my opinion should provide a way to release its resources,
as a developper using copmmons.filepload don't have to know that is used for encapsulation

So what is the solution ? 

A common solution to this problems is to use classloaders. should provide a method
to stop the thread, or better to release resources,  as a user of I don't have
to know about the thread. This method should take as parameter the classloader of the application
requesting the resources release. If the given classloader is the same as the classloader
of FileCleaner, this means that the lib has been deployed inside the war, so the thread should
be stopped and all resources released. If the classloader is different, then the thread is
owned by the container, so don't stop it. But release other resources associated to the given
classloader (listeners, cache ...) that may cause a classloader leak.

I hope I've been clear and my clues will help you. If any question remains, don't hesitate
to ask for details, I watch this thread.

> FileCleaner thread never ends and cause memory leak in AS
> ---------------------------------------------------------
>                 Key: IO-99
>                 URL:
>             Project: Commons IO
>          Issue Type: Bug
>    Affects Versions: 1.2
>         Environment: JBOssPortal with commons.fileupload
>            Reporter: Vera Mickaël
>            Priority: Critical
> 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:
For more information on JIRA, see:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message