[infinispan-issues] [JBoss JIRA] Updated: (ISPN-772) Thread local storage keeping reference to an org.infinispan.context.impl.LocalTxInvocationContext

Scott Marlow (JIRA) jira-events at lists.jboss.org
Mon Nov 15 16:33:43 EST 2010


     [ https://jira.jboss.org/browse/ISPN-772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow updated ISPN-772:
------------------------------

    Description: 
I'm seeing the following sequence of invocations during AS cluster classloader leak unit tests:

1.  InvocationContextContainerImpl.createInvocationContext creates a new
LocalTxInvocationContext (lets call it #3011) and sets thread local
(icTL) to it.

2.  InvocationContextContainerImpl.suspend() LocalTxInvocationContext
#3011 which clears the thread local reference.

3.  We InvocationContextContainerImpl.resume() LocalTxInvocationContext
#3011 which sets the thread local reference.

4.  We InvocationContextContainerImpl.suspend() LocalTxInvocationContext
#3011 which clears the thread local reference.

5.  We InvocationContextContainerImpl.resume() LocalTxInvocationContext
#3011 which sets the thread local reference.

I don't see another suspend call, so LocalTxInvocationContext #3011 is
still referenced by the thread local InvocationContextContainerImpl.icTL which keeps the classloader in memory (the icTL reference is the only reference to the classloader).

Call stack showing where the LocalTxInvocationContext was created from http://pastie.org/1300157


  was:
I'm seeing the following sequence of invocations during AS cluster classloader leak unit tests:

1.  InvocationContextContainerImpl.createInvocationContext creates a new
LocalTxInvocationContext (lets call it #3011) and sets thread local
(icTL) to it.

2.  InvocationContextContainerImpl.suspend() LocalTxInvocationContext
#3011 which clears the thread local reference.

3.  We InvocationContextContainerImpl.resume() LocalTxInvocationContext
#3011 which sets the thread local reference.

4.  We InvocationContextContainerImpl.suspend() LocalTxInvocationContext
#3011 which clears the thread local reference.

5.  We InvocationContextContainerImpl.resume() LocalTxInvocationContext
#3011 which sets the thread local reference.

I don't see another suspend call, so LocalTxInvocationContext #3011 is
still referenced by the thread local InvocationContextContainerImpl.icTL which keeps the classloader in memory (the icTL reference is the only reference to the classloader).





> Thread local storage keeping reference to an org.infinispan.context.impl.LocalTxInvocationContext 
> --------------------------------------------------------------------------------------------------
>
>                 Key: ISPN-772
>                 URL: https://jira.jboss.org/browse/ISPN-772
>             Project: Infinispan
>          Issue Type: Bug
>            Reporter: Scott Marlow
>            Assignee: Manik Surtani
>             Fix For: 4.2.0.CR1
>
>
> I'm seeing the following sequence of invocations during AS cluster classloader leak unit tests:
> 1.  InvocationContextContainerImpl.createInvocationContext creates a new
> LocalTxInvocationContext (lets call it #3011) and sets thread local
> (icTL) to it.
> 2.  InvocationContextContainerImpl.suspend() LocalTxInvocationContext
> #3011 which clears the thread local reference.
> 3.  We InvocationContextContainerImpl.resume() LocalTxInvocationContext
> #3011 which sets the thread local reference.
> 4.  We InvocationContextContainerImpl.suspend() LocalTxInvocationContext
> #3011 which clears the thread local reference.
> 5.  We InvocationContextContainerImpl.resume() LocalTxInvocationContext
> #3011 which sets the thread local reference.
> I don't see another suspend call, so LocalTxInvocationContext #3011 is
> still referenced by the thread local InvocationContextContainerImpl.icTL which keeps the classloader in memory (the icTL reference is the only reference to the classloader).
> Call stack showing where the LocalTxInvocationContext was created from http://pastie.org/1300157

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


More information about the infinispan-issues mailing list