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)
