[jira] [Created] (IGNITE-13130) Possible memory leak in IgniteH2Indexing

["HubertL (Jira)" <ji...@apache.org>]

HubertL created IGNITE-13130:
--------------------------------

             Summary: Possible memory leak in IgniteH2Indexing
                 Key: IGNITE-13130
                 URL: https://issues.apache.org/jira/browse/IGNITE-13130
             Project: Ignite
          Issue Type: Bug
          Components: cache
    Affects Versions: 2.8.1
         Environment: Linux
            Reporter: HubertL
         Attachments: Capture.PNG

Version 2.8 / 2.8.1 both leaks memory in my case where the cache is used. From the leak suspect report the leak can be attributed to the hash "runs" under org.apache.ignite.internal.processors.query.RunningQueryManager, which is called by IgniteH2Indexing to register queries. It seems some queries got registered but never removed (by RunningQueryManager.unregister()).  The following is the report from heap dump, both may be caused by the issue:
{quote}One instance of "java.util.concurrent.ConcurrentHashMap" loaded by "<system class loader>" occupies 348,001,008 (36.33%) bytes. The instance is referenced by org.apache.ignite.internal.processors.query.RunningQueryManager @ 0x813ae260 , loaded by "org.springframework.boot.loader.LaunchedURLClassLoader @ 0x80000000". The memory is accumulated in one instance of "java.util.concurrent.ConcurrentHashMap$Node[]" loaded by "<system class loader>".

63,364 instances of "org.apache.ignite.internal.processors.query.h2.H2ConnectionWrapper", loaded by "org.springframework.boot.loader.LaunchedURLClassLoader @ 0x80000000" occupy 331,745,704 (34.63%) bytes. These instances are referenced from one instance of "java.util.concurrent.ConcurrentHashMap$Node[]", loaded by "<system class loader>"
{quote}
From the source the only place where calls to RunningQueryManager.register() which is not guarentee to be followed by unregister() is executeSelect() under IgniteH2Indexing.java, where the call to registerRunningQuery (which in turn calls RunningQueryManager.register()) is not matched by RunningQueryManager.unregister() except where exception occurred (lines 1274 and 1333 of IgniteH2Indexing.java).  This is strange since other similar functions (e.g. executeDml() above) puts RunningQueryManager.unregister() in a finally block after calling register().

Is the unmatched call to register (in case of success) deliberate? Could this be the source of leak?

 



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