You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@geode.apache.org by "Kirk Lund (Jira)" <ji...@apache.org> on 2019/10/28 19:26:00 UTC

[jira] [Updated] (GEODE-7370) ClassGraph library causes large memory leak in Geode after adding geode-log4j

     [ https://issues.apache.org/jira/browse/GEODE-7370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kirk Lund updated GEODE-7370:
-----------------------------
    Description: 
According to the source code and documentation, io.github.classgraph.ScanResult must be closed to avoid memory and file leaks.

I identified a large memory leak that apparently after adding geode-log4j. Surprisingly the cause ended up being an instance of ScanResult which is used by the management code to search the classpath for user classes that implement geode functions or gfsh commands.

Geode currently depends on ClassGraph version 4.0.6, but the library is up to version 4.8.52 (averaging around a dozen releases per month).

JVM bytes in use by io.github.classgraph after closing all ScanResult instances:
* Before geode-log4j with ClassGraph 4.0.6: 20,488 bytes
* Before geode-log4j with ClassGraph 4.8.52: 1,056 bytes
* After geode-log4j with ClassGraph 4.0.6: 56,753,008 bytes
* After geode-log4j with ClassGraph 4.8.52: 1,056 bytes

Given the above results of my testing, I believe we need to keep this dependency up-to-date and upgrade to 4.8.52.

  was:
According to the source code and documentation, io.github.classgraph.ScanResult must be closed to avoid memory and file leaks.

I identified a large memory leak surrounding the commit which introduced geode-log4j. Surprisingly the cause ended up being an instance of ScanResult.

Geode currently depends on ClassGraph version 4.0.6, but the library is up to version 4.8.52 (averaging around a dozen releases per month).

JVM bytes in use by io.github.classgraph after closing all ScanResult instances:
* Before geode-log4j with ClassGraph 4.0.6: 20,488 bytes
* Before geode-log4j with ClassGraph 4.8.52: 1,056 bytes
* After geode-log4j with ClassGraph 4.0.6: 56,753,008 bytes
* After geode-log4j with ClassGraph 4.8.52: 1,056 bytes

Given the above results of my testing, I believe we need to keep this dependency up-to-date and upgrade to 4.8.52.


> ClassGraph library causes large memory leak in Geode after adding geode-log4j
> -----------------------------------------------------------------------------
>
>                 Key: GEODE-7370
>                 URL: https://issues.apache.org/jira/browse/GEODE-7370
>             Project: Geode
>          Issue Type: Bug
>          Components: management
>            Reporter: Kirk Lund
>            Priority: Major
>
> According to the source code and documentation, io.github.classgraph.ScanResult must be closed to avoid memory and file leaks.
> I identified a large memory leak that apparently after adding geode-log4j. Surprisingly the cause ended up being an instance of ScanResult which is used by the management code to search the classpath for user classes that implement geode functions or gfsh commands.
> Geode currently depends on ClassGraph version 4.0.6, but the library is up to version 4.8.52 (averaging around a dozen releases per month).
> JVM bytes in use by io.github.classgraph after closing all ScanResult instances:
> * Before geode-log4j with ClassGraph 4.0.6: 20,488 bytes
> * Before geode-log4j with ClassGraph 4.8.52: 1,056 bytes
> * After geode-log4j with ClassGraph 4.0.6: 56,753,008 bytes
> * After geode-log4j with ClassGraph 4.8.52: 1,056 bytes
> Given the above results of my testing, I believe we need to keep this dependency up-to-date and upgrade to 4.8.52.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)