memory leak due to classloader leak (in commons.io)

• Key: FILEUPLOAD-120
• Type: Bug
• Status: Closed
• Resolution: Fixed
• Priority: Major
• Assignee: Unassigned
• Reporter: Vera Mickaël
• Affects Version/s: 1.1.1
• Fix Version/s: 1.2

Description

commons.io opens a thread that is never stopped. The result is that a reference from a container class (jboss threads pool) to my webapp classloader is never released and my webapp classloader is never garbaged. After serveral deploy/undeploy cycles I experience an "OutOfMemoryError : PermGen".

I did open an issue in commons.io : https://issues.apache.org/jira/browse/IO-99

I also open an issue here as I think commons.fileupload have concerns about webapp environnements

Comments

[Jochen Wiedmann]

As you have found not only the problem, but the reason as well, I believe that there doesn't remain any work for the FILEUPLOAD team. Consequently, I am resolving this as "Invalid" (must be fixed externally). Thanks for reporting this.

[Vera Mickaël]

I don't feel like my issue is invalid.

This is really a commons.fileupload bug as commons.fileupload depends on a lib that isn't designed to be embeded in a webapp.

I did open an issue in commons.fileupload because I expected developpers of fileuploads to be concerned by hot deploy in web servers more than commons.io Could someone of the commons.fileupload support my issue in commons.io by voting for it in commons.io, and add a comment supporting my description of the problem.

This a complex problem with a very simple solution, any support for the commons.io team is welcome.

[Henri Yandell]

Reopening - it seems to me that if the IO feature is added, then we'll need to make sure FileUpload use it. So this seems like a good issue to record the need for FileUpload to use the IO bit [see Martin's comments in IO-99].

[Vera Mickaël]

I proposed a solution on commons.io, an API using the classloader to release resources. I thought that maybe commons.fileupload may offer the same service and delegate a part of it to commons.io. As I don't use directly commons.io, I'd prefer to ask commons.fileupload to release its resources better than to commons.io

Thanks for reopening this issue, IMHO the new status reflects better the situation.

[Henri Yandell]

Sounds like FileUpload 1.2 is waiting on IO 1.3 so it can fix this. As far as I understand, FileUpload will need a small amount of code change.

[Jochen Wiedmann]

> Sounds like FileUpload 1.2 is waiting on IO 1.3 so it can fix this. As far as I understand, FileUpload will need a small amount of code change.

Dunno. My intention was to wait for 1.3, then change the POM's (Maven 1 and 2) and see what happens.

[Henri Yandell]

I think we need to get it in FileUpload earlier than that so we can be happy releasing 1.3.

[Henri Yandell]

I'm being dumb. So Vera needs to grab the latest nightly IO and add a call to FileCleaner.exitWhenFinished in javax.servlet.ServletContextListener#contextDestroyed().

Such a thing is attached. I don't know if we want to ship that in FileUpload or not.

[Henri Yandell]

Here's the web.xml, to save anyone reading this from having to look it up.

<web-app>
<listener>
<listener-class>
org.apache.commons.fileupload.FileCleanerCleanup
</listener-class>
</listener>

.....

[Jochen Wiedmann]

I agree with you, Henri, that it makes sense to provide a servletcontextlistener. Question: I would assume that there is a similar thing for portlets, is it? Can anyone provide an implementation for that as well?

[Henri Yandell]

Looking at http://portals.apache.org/pluto/pluto-container/apidocs/index.html - I don't see any obvious Listener classes. I figure we can just release FileUpload and let someone contribute a portlet listener if it's important to them.

[Jochen Wiedmann]

Ok, IO-99 is resolved, Henri's patch is in, so I am now resolving this issue.