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

[Marko Strukelj (JIRA)]

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

Marko Strukelj commented on JBVFS-159:
--------------------------------------

ZipEntryInputStream (later upgraded to CertificateReaderInputStream which just added extra functionality for reading certificates) is there to provide reference counting for usages of underlying ZipFileWrapper. 

Without it ZipFileWrapper will increase refCount for every newly read class/resource but never decrease it. The result is a permanent file handle leak which on windows systems makes it impossible to delete the file. After enough time the counter would go beyond MAX_VALUE and into negative territory potentially causing closing of underlying ZipFile despite outstanding yet unread ZipEntryInputStream - triggering IOException on class/resource loading. If incrementing of refCount is disabled such an arbitrary closing will go into effect immediately.

To put it simply - this class plays a role, you may eventually experience problems having commented it out.

One possible reason for increased memory usage might be the use of finalize(). The finalize() method is not particularly important - it's just a final safety net for code that forgets to close unfully read streams - mainly here for possible buggy third party libraries on which you as a developer may not have much influence. Removing it could cause existing applications using buggy libraries, and running on Windows to start develop file locking problems, and this can not be made configurable as a class either has a finalize() method or doesn't - and that is not configurable ... although there might be complicated workarounds for that as well ...

Could you repeat your test by removing your initial code comments and by commenting out just the finalize() method, so that we see if this is the cause?



> 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