Comment #24 on issue 288 by [email protected]:
FinalizableReferenceQueue still leaks
http://code.google.com/p/google-guice/issues/detail?id=288
FWIW I am using a slightly changed version of Guice that doesn't leak on
redeploy. See the svn patch (against tagged 2.0 release). Basically I just
get rid of non-strong maps that cause the finalizer thread to start.
Changes made:
o) StackTraceElements originally uses weak.soft map(Thread). I've replaced
this with a plain strong map which is cleared when Guice ends reporting
errors.
o) BytecodeGen uses a weak.weak cache(Thread). I've put the cache in IODH
(lazy singleton). I see that the latest code also follows a similar
approach. Therefore if bridging is disabled the thread will not be started.
o) I've made bridging disabled by default as I don't see any added value
for a plain servlet setup. It works also on WebSphere and don't see the
point of making sure my co-workers diligently disable the bridging. Besides
putting Guice in boot class path still produces a memory leak...
o) Replaced ThreadLocal with a plain concurrent map so Tomcat no longer
spams with SEVERE ThreadLocal not cleared warning. It is less than 2x
slower but this is acceptable price for me. I don't expect this to be
popular choice.
I wouldn't be surprised if at Google they have a custom JDK that has this
functionality built in.
Attachments:
RedeplyForGuice.patch 7.2 KB
--
You received this message because you are subscribed to the Google Groups
"google-guice-dev" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/google-guice-dev?hl=en.
