[ http://issues.apache.org/jira/browse/IO-99?page=comments#action_12451376 ] 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 commons.io. I think is that backward compatibility is important and that you should keep the thread automatically started. 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 commons.io and I want my lib to be compatible with web containers environement, as commons.filepload for example. commons.filepload don't know if commons.io 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 commons.io is used for encapsulation reasons. So what is the solution ? A common solution to this problems is to use classloaders. commons.io should provide a method to stop the thread, or better to release resources, as a user of commons.io 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: 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 > 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: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
