[jboss-jira] [JBoss JIRA] (WFLY-2605) TCCL leak in infinispan transaction reaper thread

[Brent Douglas (JIRA)]

    [ https://issues.jboss.org/browse/WFLY-2605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12931959#comment-12931959 ] 

Brent Douglas edited comment on WFLY-2605 at 12/16/13 7:01 PM:
---------------------------------------------------------------

[~pferraro] As you say, not using eager start stops hibernates cache leaking. Clearly that cache should not be eager started. I was a little unclear what was going on when I filed this but I think I can see use cases where this is an actual problem, and one that now I have a better idea what is going on, they are cases that I would actually like to use. For example if I pre-cache a bunch of stuff (for arguments sake say I'm only caching <Integer,BigDecimal>) which is calculated on startup and takes a significant amount of time. During a development it would be super handy to be able to run this cache as an eager starting cache so that redeploying the app doesn't need to refill this every time.

>From what I understand this is due to the way that threads are created in infinispan. When created they are assigned the tccl of the current thread, which will generally be my deployments loader. With eager loading caches this will stop my app from being undeployed. I tried altering the classloader of these threads to use infinispan's loader and I no longer have these issues. Obviously if I still have anything from my loader in the cache it still can't be undeployed but it would be good to have the option to allow undeploying if you are careful with what is in the persistent caches rather than just not being able to undeploy artifacts at all when using them. Does that make sense?

Anyway, I am going to submit a PR to infinispan and see where that goes.
                
      was (Author: brentdouglas):
    Paul Ferraro As you say, not using eager start stops hibernates cache leaking. Clearly that cache should not be eager started. I was a little unclear what was going on when I filed this but I think I can see use cases where this is an actual problem, and one that now I have a better idea what is going on, they are cases that I would actually like to use. For example if I pre-cache a bunch of stuff (for arguments sake say I'm only caching <Integer,BigDecimal>) which is calculated on startup and takes a significant amount of time. During a development it would be super handy to be able to run this cache as an eager starting cache so that redeploying the app doesn't need to refill this every time.

>From what I understand this is due to the way that threads are created in infinispan. When created they are assigned the tccl of the current thread, which will generally be my deployments loader. With eager loading caches this will stop my app from being undeployed. I tried altering the classloader of these threads to use infinispan's loader and I no longer have these issues. Obviously if I still have anything from my loader in the cache it still can't be undeployed but it would be good to have the option to allow undeploying if you are careful with what is in the persistent caches rather than just not being able to undeploy artifacts at all when using them. Does that make sense?

Anyway, I am going to submit a PR to infinispan and see where that goes.
                  
> TCCL leak in infinispan transaction reaper thread
> -------------------------------------------------
>
>                 Key: WFLY-2605
>                 URL: https://issues.jboss.org/browse/WFLY-2605
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering, JPA / Hibernate
>    Affects Versions: 8.0.0.Beta1
>         Environment: Fedora 19, Oracle 7u45, Wildfly 7952aa65e67e1d
>            Reporter: Brent Douglas
>            Assignee: Paul Ferraro
>
> The reaper thread created in [TransactionTable|https://github.com/infinispan/infinispan/blob/master/core/src/main/java/org/infinispan/transaction/TransactionTable.java?source=cc] is leaking a deployment module classloader. I have observed by deploying and undeploying the same artifact a couple of times over that only the first deployment is held.
> !http://i.imgur.com/M37pHSe.png!

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira