[
https://issues.apache.org/jira/browse/IGNITE-13130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
HubertL updated IGNITE-13130:
-----------------------------
Description:
Version 2.8 / 2.8.1 both leaks memory in my case where the cache is used with
SQL query. 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?
I have to fallback to version 2.7.6 (before the recent changes to
IgniteH2Indexing) which does not have the issue.
was:
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?
> 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
> Priority: Critical
> Attachments: Capture.PNG
>
>
> Version 2.8 / 2.8.1 both leaks memory in my case where the cache is used with
> SQL query. 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?
> I have to fallback to version 2.7.6 (before the recent changes to
> IgniteH2Indexing) which does not have the issue.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
