[jboss-jira] [JBoss JIRA] Commented: (JBVFS-159) Native memory leak due to ZipEntryInputStream

[Samuel Cai (JIRA)]

    [ https://jira.jboss.org/browse/JBVFS-159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12536215#action_12536215 ] 

Samuel Cai commented on JBVFS-159:
----------------------------------

Thank you Marko for your quick response.
I tried the test by removing finalize method in ZipEntryInputStream, unfortunately, that doesn't help.

I don't think it will have file handle leak, every ZipFileWrapper instance only has one ZipFile instance, i.e. holds one file handle, so if the ZipFileWrapper instance is reused, that's ok, if not, then will be GCed, the ZipFile instance will then call finalize method to release file handle and streams.

I'm just wondering if we should introduce ZipEntryInputStream class, in our case, if steam isn't closed in the first place but just rely on ZipFile to close, a native memory leak will happen, but unfortunately I still didn't find the root cause, checking heap dump didn't help.
I observed one thing that process size grows very fast when JBoss is processing and caching annotations which utilizes VFS a lot, and also javassist, not sure if the root cause is related to javassist.

> Native memory leak due to ZipEntryInputStream
> ---------------------------------------------
>
>                 Key: JBVFS-159
>                 URL: https://jira.jboss.org/browse/JBVFS-159
>             Project: JBoss VFS
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.1.2.GA
>         Environment: Redhat (not sure what version) 2.6.9-78.ELsmp
> JBoss 5.1.0.GA
> JDK 1.6.0_20
> JVM parameter:
> -XX:+PrintGCTimeStamps -XX:+PrintGCApplicationStoppedTime -verbose:gc -Dfile.encoding=iso-8859-1 -server -Djava.net.preferIPv4Stack=true -Doracle.jdbc.V8Compatible=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Dnetworkaddress.cache.ttl=300 -Xss128k -Xmn500m -Dorg.apache.jasper.runtime.BodyContentImpl.LIMIT_BUFFER=true -XX:+PrintGCDetails -XX:PermSize=256m -XX:MaxPermSize=256m -Xms1500m -Xmx1500m -XX:+HeapDumpOnOutOfMemoryError -XX:+UseConcMarkSweepGC 
>            Reporter: Samuel Cai
>            Assignee: Marko Strukelj
>
> We used to use JBoss 4.2.1.GA and JDK 1.6.0_11, and trying JBoss 5.1.0.GA and JDK 1.6.0_20 these days.
> I found the process size is more larger than before, 2.5G~2.9G compared to 1.9G.
> I was thinking this was a bug of JBoss AS, then filed https://jira.jboss.org/browse/JBAS-8066
> After these days investigation, I think this is a memory leak in VFS, maybe only happen on our specific environment.
> I tried a change on class org.jboss.virtual.plugins.context.zip.ZipFileWrapper, method openStream:
> From:
> ZipEntryInputStream zis = new ZipEntryInputStream(this, is);
> return zis;
> To:
> //ZipEntryInputStream zis = new ZipEntryInputStream(this, is);
> //return zis;
> return is;
> That is, don't use ZipEntryInputStream, let any class/method invoking openStream to close zipFile's inputStream immediatelly.
> ZipFile will be in open status, but all steams will be closed well.
> This makes the process size down to same as JBoss 4's. I tried going through first 3 pages of site, no problems. May need QA team to test more.
> Btw, I tried updating VFS to 2.1.3.SP1/2.2.0.M4/3.0.0.CR5, first two have same size issue, third one couldn't start.

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