[
https://issues.apache.org/jira/browse/GERONIMO-4869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevan Miller reassigned GERONIMO-4869:
--------------------------------------
Assignee: Kevan Miller
> InheritableThreadLocal causing ClassLoader memory leak in TransactionTimer
> thread
> ---------------------------------------------------------------------------------
>
> Key: GERONIMO-4869
> URL: https://issues.apache.org/jira/browse/GERONIMO-4869
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Affects Versions: 2.1.4
> Reporter: Kevan Miller
> Assignee: Kevan Miller
> Fix For: 2.1.5, 2.2
>
>
> Another problem i saw in the .hprof data provided by Ghostknife was caused by
> a threadlocal in the o.a.g.transaction.manager.TransactionTimer$CurrentTime
> thread
> {code}
> Class Name
>
> | Shallow Heap | Retained Heap
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> classLoader org.apache.geronimo.naming.reference.PersistenceContextReference
> @ 0xac810698
> | 48 | 1,440
> '- value java.util.HashMap$Entry @ 0xac836450
>
> | 24 | 144
> '- [0] java.util.HashMap$Entry[16] @ 0xac833910
>
> | 80 | 592
> '- table java.util.HashMap @ 0xac831f58
>
> | 40 | 632
> '- m java.util.Collections$UnmodifiableMap @ 0xac8304b0
>
> | 24 | 656
> '- absoluteIndex org.apache.xbean.naming.context.ImmutableContext
> @ 0xac82f470
> | 40 | 4,880
> '- key java.util.LinkedHashMap$Entry @ 0xac840310
>
> | 32 | 4,912
> '- [4] java.util.HashMap$Entry[16] @ 0xac8401b0
>
> | 80 | 80
> '- table java.util.LinkedHashMap @ 0xac83fe98
>
> | 48 | 5,088
> '- map java.util.LinkedHashSet @ 0xac83dac0
>
> | 16 | 5,104
> '- c java.util.Collections$UnmodifiableSet @
> 0xac83d588
> | 16 | 5,120
> '- value
> java.util.concurrent.atomic.AtomicReference @ 0xac83d080
> |
> 16 | 5,136
> '- federatedContextRef
> org.apache.xbean.naming.context.ContextFederation @ 0xac8386e0
> | 16 |
> 5,152
> '- contextFederation
> org.apache.xbean.naming.context.WritableContext$NestedWritableContext @
> 0xac837720 | 56 |
> 5,704
> '- value java.util.HashMap$Entry @
> 0xac899150
> | 24 | 80
> '- [13] java.util.HashMap$Entry[16]
> @ 0xac897a20
> | 80 | 880
> '- table java.util.HashMap @
> 0xac894d90
> | 40 | 920
> '- value
> java.util.concurrent.atomic.AtomicReference @ 0xac830548
> | 16 |
> 936
> '- bindingsRef
> org.apache.xbean.naming.context.WritableContext$NestedWritableContext @
> 0xac82f498 | 56 |
> 11,352
> '- value
> java.lang.ThreadLocal$ThreadLocalMap$Entry @ 0xac8a2f50
> | 32 |
> 11,384
> '- [6]
> java.lang.ThreadLocal$ThreadLocalMap$Entry[16] @ 0xac8a20f8
> | 80 | 11,688
> '- table
> java.lang.ThreadLocal$ThreadLocalMap @ 0xac8a0c08
> | 24 | 11,712
> '-
> inheritableThreadLocals
> org.apache.geronimo.transaction.manager.TransactionTimer$CurrentTime @
> 0xac89dcf8 Thread-24 Thread| 88 | 11,880
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> {code}
> CurrentTime does not create a ThreadLocal. However, it can "inherit" an
> InheritableThreadLocal from the parent Thread (the currentThread, when it is
> created). This is obviously what is happening, in this case. Best solution
> that I have so far, is to force the creation of the TransactionTimer thread
> during server start, rather than allowing it to be started on an arbitrary
> thread...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
