Open GoogleCodeExporter opened 9 years ago
Related discussion thread:
http://groups.google.com/group/google-guice/browse_thread/thread/bac22d152fe2d25
7/531dcc0ffd08e11d#531dcc0ffd08e11d
Original comment by gili.tza...@gmail.com
on 17 Nov 2008 at 10:32
This has been fixed in Google Collections. We just need to bring over the new
version.
Original comment by crazybob...@gmail.com
on 17 Nov 2008 at 11:01
Excellent. I'm eagerly awaiting this update! I've been suffering from major
webapp
deployment problems related to memory leaks over the past five (!!) years.
Being able
to develop webapps without having to restart the web server every five minutes
would
be a dream come true :) Thank you!
Original comment by gili.tza...@gmail.com
on 18 Nov 2008 at 5:21
I brought in the new version of Google Collections in r708.
Original comment by limpbizkit
on 29 Nov 2008 at 10:22
Jesse, I don't think this is enough. You should probably keep this issue open
until
http://code.google.com/p/google-collections/issues/detail?id=92#c6 is fixed.
Original comment by gili.tza...@gmail.com
on 29 Nov 2008 at 10:34
Stuart's patch exploits the fact that he can reflectively change some private
fields - this is very fragile stuff.
Creating a new thread is a reasonable thing to do, and we shouldn't have to
write hacks to make that safe.
Especially since the hacks break portability between JVMs (and possibly between
app servers).
So what we really need a safe, hack-free way to use background threads that
works in both Java SE and EE.
Gili, could you talk to the Glassfish folks and see if they can address this on
their end?
Original comment by limpbizkit
on 29 Nov 2008 at 11:58
Jesse,
I filed a new bug report:
https://glassfish.dev.java.net/issues/show_bug.cgi?id=6857
Original comment by gili.tza...@gmail.com
on 30 Nov 2008 at 2:22
Yeah, those reflection hacks are totally flaky and I didn't expect them to go
into
google-collections, but using doPrivileged when creating the Finalizer thread
and
pro-actively setting the TCCL to null are IMHO a good idea.
The dangling inherited-thread-local can be fixed in the GlassFish worker pool,
which
just leaves the access-control-context issue in the classloader. Again this
might be
possible to fix in GlassFish, but I'm not sure as it involves Java security
which is
a headache to follow at the best of times :)
Original comment by mccu...@gmail.com
on 30 Nov 2008 at 10:58
Also be aware that Guice has its own copy of some of the Google-Collections
code,
including the Finalizer thread - I coded up a patch to fix this when I was
testing
the other issue:
http://peaberry.googlecode.com/svn/branches/spike/lib/build/google-guice-patch-2
27.txt
I still had to keep copies of a few classes from Google-Collections (such as the
ReferenceMap) to fix some visibility issues but I sync'd them with the version
in
Google-Collections. Also the tests for ReferenceMap have an unfortunate
dependency on
the relocated package name (because they aren't JarJar'd) but it's a start...
Original comment by mccu...@gmail.com
on 30 Nov 2008 at 12:46
How can this issue be fixed if
http://code.google.com/p/google-collections/issues/detail?id=92 is still open?
Original comment by gili.tza...@gmail.com
on 22 Oct 2009 at 5:03
There seems to be another issue report for it:
http://code.google.com/p/google-guice/issues/detail?id=288.
Original comment by syva...@yahoo.com
on 26 Oct 2009 at 2:10
But you probably knew that already as you seem to have originally reported it :)
Original comment by syva...@yahoo.com
on 26 Oct 2009 at 2:13
Original issue reported on code.google.com by
limpbizkit
on 4 Aug 2008 at 7:43