ignite-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Valentin Kulichenko (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (IGNITE-967) Internal thread locals are not always cleaned
Date Tue, 02 Jun 2015 04:14:17 GMT

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

Valentin Kulichenko updated IGNITE-967:
---------------------------------------
    Description: 
One of our users reported that he sees warnings in Tomcat's log when the application that's
running Ignite in embedded mode is undeployed:
{code}
SEVERE: The web application [/XXX] created a ThreadLocal with key of type [org.apache.ignite.internal.util.GridSpinReadWriteLock$1]
(value [org.apache.ignite.internal.util.GridSpinReadWriteLock$1@2c2858af]) and a value of
type [java.lang.Integer] (value [0]) but failed to remove it when the web application was
stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.
{code}
There is also the similar warning for {{GridToStringBuilder.threadCache}}. 

While it's usually OK not to clean thread locals on standalone node, in app server it can
cause a memory leak.

To avoid such issues I suggest to add a special step after all test suites that will check
thread locals in test runner thread. If we have this check in CI, we will fix it once and
for always.

Thread local values can be introspected through {{Thread.threadLocals}} variable. It would
also be a good idea to check Tomcat's sources on how it's done there.

  was:
One of our users reported that he sees warnings in Tomcat's log when the application that's
running Ignite in embedded mode is undeployed:
{noformat}
SEVERE: The web application [/XXX] created a ThreadLocal with key of type [org.apache.ignite.internal.util.GridSpinReadWriteLock$1]
(value [org.apache.ignite.internal.util.GridSpinReadWriteLock$1@2c2858af]) and a value of
type [java.lang.Integer] (value [0]) but failed to remove it when the web application was
stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.
{noformat}
There is also the similar warning for {{GridToStringBuilder.threadCache}}. 

While it's usually OK not to clean thread locals on standalone node, in app server it can
cause a memory leak.

To avoid such issues I suggest to add a special step after all test suites that will check
thread locals in test runner thread. If we have this check in CI, we will fix it once and
for always.

Thread local values can be introspected through {{Thread.threadLocals}} variable. It would
also be a good idea to check Tomcat's sources on how it's done there.


> Internal thread locals are not always cleaned
> ---------------------------------------------
>
>                 Key: IGNITE-967
>                 URL: https://issues.apache.org/jira/browse/IGNITE-967
>             Project: Ignite
>          Issue Type: Bug
>          Components: general
>    Affects Versions: sprint-4
>            Reporter: Valentin Kulichenko
>
> One of our users reported that he sees warnings in Tomcat's log when the application
that's running Ignite in embedded mode is undeployed:
> {code}
> SEVERE: The web application [/XXX] created a ThreadLocal with key of type [org.apache.ignite.internal.util.GridSpinReadWriteLock$1]
(value [org.apache.ignite.internal.util.GridSpinReadWriteLock$1@2c2858af]) and a value of
type [java.lang.Integer] (value [0]) but failed to remove it when the web application was
stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.
> {code}
> There is also the similar warning for {{GridToStringBuilder.threadCache}}. 
> While it's usually OK not to clean thread locals on standalone node, in app server it
can cause a memory leak.
> To avoid such issues I suggest to add a special step after all test suites that will
check thread locals in test runner thread. If we have this check in CI, we will fix it once
and for always.
> Thread local values can be introspected through {{Thread.threadLocals}} variable. It
would also be a good idea to check Tomcat's sources on how it's done there.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message