db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-3745) Derby can leak classloaders in an app server environment
Date Thu, 10 Jul 2008 12:42:33 GMT

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

Knut Anders Hatlen commented on DERBY-3745:
-------------------------------------------

Thanks for the new patch! If I have understood correctly what a context class loader is, I
don't think the patch should do any harm (none of Derby's daemon threads should ever use the
context class loader, should they?). I just had a feeling that we might have been trying to
fix the problem the wrong place, but I think you're right that the impact of the fix should
be limited, so I'm fine with it.

If it is the case that some of Derby's threads are not stopped when the driver is unloaded,
that should be treated as a bug, and a separate JIRA issue should be filed for it to get it
fixed.

(Two tiny nits: (a) one line in one of the comment in SingletonTimerFactory is indented with
space+tab+space, and (b) trailing white-space has been added after the end-of-method brace
in the same file)

> 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.0.0
>            Reporter: Kathey Marsden
>            Assignee: Kathey Marsden
>         Attachments: derby-3745_10.3_diff.txt, derby-3745_10.3_diff2.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 is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message