[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=12537101#action_12537101 ] 

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


I tried your proposed patch on Windows and on Linux, and the results are contrary to each other.

On Linux I find the memory footprint of the process is noticably improved, but on Windows it is noticably worsened. The reason seems to be that your patch actually increases heap usage baseline. But the native zip memory leak on Linux is obviously so big that fixing it offsets the increased heap usage. On Windows there apparently is no native zip memory leak and so there's no gain on that front that would offset extra heap usage.

My patch on the other hand doesn't address native zip memory leak at all, but attempts to reduce heap size used by vfszip metadata. That would maybe allow you to decrease -Xmx memory size by about 10% which will again translate to decreased process size.

So the combination of both patches should be most beneficial on Linux, while it appears it's best to avoid using your patch on Windows.


> 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
>         Attachments: change.tar.gz, JBVFS-159.patch, leakdetector.jar, test.zip, VFSZipMemoryTestCase.java
>
>
> 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