[
https://issues.jboss.org/browse/WFLY-2605?page=com.atlassian.jira.plugin....
]
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/cor...]
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