Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Date: Mon, 25 Aug 2014 17:58:58 +0000 (UTC)
From: "ASF subversion and git services (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Message-ID: <JIRA.12399325.1214868630252.5643.1408989538657@arcas>
In-Reply-To: <JIRA.12399325.1214868630252@arcas>
References: <JIRA.12399325.1214868630252@arcas>
Subject: [jira] [Commented] (DERBY-3745) Derby can leak classloaders in an
 app server environment
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/DERBY-3745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14109400#comment-14109400 ] 

ASF subversion and git services commented on DERBY-3745:
--------------------------------------------------------

Commit 1620392 from [~dagw] in branch 'code/branches/10.11'
[ https://svn.apache.org/r1620392 ]

DERBY-6619 After silently swallowing SecurityExceptions, Derby can leak class loaders

Backported from trunk svn 1620385.

Patch derby-6619-2-refinement which implements the following
refinements to the test to avoid changing the context class loader in
SingletonTimerFactory (suggested by Knut):

The orginal test tested against the system class loader. This new
patch will:

1) Check if the context class loader is the same as the loader of the
SingletonTimerFactory class (that is, the class loader from which
Derby classes are loaded). Even if this isn't the same as the system
class loader, it would be safe to skip the workaround for DERBY-3745,
since the class loader for the Derby classes would not be eligible for
garbage collection until the engine is shut down anyway. This would
prevent some more false positives from being reported in
derby.log. I'd assume this is a kind of false positive that could
easily occur in an application server environment where the Derby
classes are not found on the system class loader.

2) Check against Thread.class.getClassLoader() instead of
ClassLoader.getSystemClassLoader(). Normally, those two checks would
be identical. If however the setup is such that they aren't identical,
we'd still know that the class loader actually used for system classes
such as the Thread class would have to stay in memory for as long as
the timer thread is alive, regardless of the context class loader of
the thread, so the workaround for DERBY-3745 can be skipped if it's
the same as the context class loader. The check will be a bit more
specific this way.

> Derby can leak classloaders in an app server environment
> --------------------------------------------------------
>
>                 Key: DERBY-3745
>                 URL: https://issues.apache.org/jira/browse/DERBY-3745
>             Project: Derby
>          Issue Type: Bug
>          Components: Services
>    Affects Versions: 10.3.3.0, 10.4.1.3, 10.5.1.1
>            Reporter: Kathey Marsden
>            Assignee: Kathey Marsden
>             Fix For: 10.3.3.1, 10.4.2.0, 10.5.1.1
>
>         Attachments: cdevbabejgjd.html, derby-3745_10.3_diff.txt, derby-3745_10.3_diff2.txt, derby-3745_BaseMonitor_cleanup_diff.txt, derby-3745_doc_diff.txt, derby-3745_fix_build_warning_diff.txt, derby-3745_policy_files_diff.txt, derby-3745_removePrivThreadOps_diff.txt, derby-3745_trunk_diff.txt, derby.log, derby3745_backport_to_104_diff_v1.txt, derby3745_backport_to_104_stat_v1.txt
>
>
> A user reported potential class loader leaks in Derby
> ...The first one looks like Derby created a long-running
> thread and copying the context class loader.  To fix, the
> context class loader should be saved/set/restored around the
> creation of the new thread so that it copies some benign class
> loader instead (e.g., null or getClass().getClassLoader()):
>  0x42278e58 java/lang/Thread@302e302e
>   [truncating at running thread LEAK]
> Object:  0x42278e58 java/lang/Thread@302e302e
> Children:
>  0x42278ee0 java/lang/String@303f303f
>  0x4226e558 java/lang/ThreadGroup@6f2e6f2e
>  0x42278e40
> org/apache/derby/impl/services/monitor/AntiGC@603a603a
>  0x419cfac0
> The second is another long running thread.  The same applies:
>  0x426fe7a0 java/lang/Thread@19901990
>   [truncating at running thread LEAK]
> Object:  0x426fe7a0 java/lang/Thread@19901990
> Parents:
>  0x4226e5a8 [Ljava/lang/Thread;@6f386f38
>  0x426fe548
> org/apache/derby/iapi/services/context/ContextManager@19421942
> Children:
>  0x426fe838 java/lang/String@19a319a3
>  0x4226e558 java/lang/ThreadGroup@6f2e6f2e
>  0x426fe4f8
> org/apache/derby/impl/services/daemon/BasicDaemon@19381938
>  0x419cfac0
> The third is a TimerThread owneed , which is created when a
> Timer is created.  The same applies:
>  0x425ac538 java/util/Timer$TimerImpl@6b8a6b8a
>   [truncating at running thread LEAK]
> Object:  0x425ac538 java/util/Timer$TimerImpl@6b8a6b8a
> Parents:
>  0x41faaf58 [Ljava/lang/Thread;@3c583c58
> Object:  0x425ac510 java/util/Timer@6b856b85
> Parents:
>  0x425ac500
> org/apache/derby/impl/services/timer/SingletonTimerFactory@56e25
> 6e2
> For more info, see thread at:
> http://www.nabble.com/ClassLoader-leaks--td18121374.html


--
This message was sent by Atlassian JIRA
(v6.2#6252)