xiaodududu / google-guice

Automatically exported from code.google.com/p/google-guice
Apache License 2.0
0 stars 0 forks source link

Exception in Finalizer in AppEngine #488

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
I have an application deployed to Appengine.
When creating injector I get the following exception :
com.google.inject.internal.FinalizableReferenceQueue$SystemLoader
loadFinalizer: Not allowed to access system class loader.
I 06-06 11:15AM 22.876
com.google.inject.internal.FinalizableReferenceQueue <init>: Failed to
start reference finalizer thread. Reference cleanup will only occur when
new references are created.
java.lang.reflect.InvocationTargetException
    at com.google.appengine.runtime.Request.process-0e64cc98a6c1b70c(Request.java)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
more ................
at com.google.inject.Guice.createInjector(Guice.java:59)
    at
com.google.forumbotty.guice.GuiceServletConfig.getInjector(GuiceServletConfig.ja
va:87)
    at
com.google.inject.servlet.GuiceServletContextListener.contextInitialized(GuiceSe
rvletContextListener.java:43)
    at
org.mortbay.jetty.handler.ContextHandler.startContext(ContextHandler.java:548)
more.................
Caused by: java.security.AccessControlException: access denied
(java.lang.RuntimePermission modifyThreadGroup)
    at
java.security.AccessControlContext.checkPermission(AccessControlContext.java:355
)
    at java.security.AccessController.checkPermission(AccessController.java:567)
    at java.lang.SecurityManager.checkPermission(Unknown Source)
    at java.lang.ThreadGroup.checkAccess(Unknown Source)
    at java.lang.Thread.init(Unknown Source)
    at java.lang.Thread.<init>(Unknown Source)
    at com.google.inject.internal.Finalizer.<init>(Finalizer.java:92)
    at com.google.inject.internal.Finalizer.startFinalizer(Finalizer.java:81)
    ... 76 more

Original issue reported on code.google.com by vega113 on 6 Jun 2010 at 7:03

Attachments:

GoogleCodeExporter commented 9 years ago
IIRC this is just an info log message letting you know that Guice couldn't 
start the finalizer thread in the more restrictive GAE environment - your 
servlet should still work (if it doesn't then that's a different issue).

Original comment by mccu...@gmail.com on 17 Jun 2010 at 4:11

GoogleCodeExporter commented 9 years ago
Not a bug, it's just an info message.

Original comment by sberlin on 18 Jun 2010 at 1:09

GoogleCodeExporter commented 9 years ago
Thanks for the answers above. You are right, sberlin, The servlet still works, 
however as I mentione before, the servlet runs on GAE and when the exception 
happens it eats a lot of CPU - for example:
/installNew?id=*** 200 8303ms 13282cpu_ms 21api_cpu_ms 0kb gzip(gfe)
request to the same servlet that doesn't cause exception
/installNew?id=*** 200 1198ms 468cpu_ms 21api_cpu_ms 0kb gzip(gfe)

The exception happens all the time and its handling eats CPU=money.
So it's not "just an info message".
I really need advice on what can be done to reduce the CPU consumption at least 
by this exception handling, or event better to prevent the exception to happen.
Thanks

Original comment by vega113 on 28 Jul 2010 at 3:23

GoogleCodeExporter commented 9 years ago
I just want to add that its really strange that Guice as a Google supported 
development doesn't integrate nicely with GAE.

Original comment by vega113 on 28 Jul 2010 at 3:26

GoogleCodeExporter commented 9 years ago
Please re-open this. 
Info messages should be generated with proper logging, not exceptions. 

Original comment by marius.a...@gmail.com on 13 Oct 2010 at 6:31

GoogleCodeExporter commented 9 years ago
My app is also experiencing this issue. 

I agree with Marius.

This should be re-opened and fixed so that an exception is not thrown.

Original comment by richpa...@gmail.com on 5 Jan 2011 at 10:02

GoogleCodeExporter commented 9 years ago
Note: the potential solution I recently attached for Issue 288 would also help 
this issue.

Original comment by mccu...@gmail.com on 12 Jan 2011 at 12:05

GoogleCodeExporter commented 9 years ago
This issue also occurs on WebSphere 7.x when the default JavaSE security policy 
is enabled. This is because the default policy prevents application code from 
creating threads (as per the EJB programming restrictions). 

Note that I've also posted on issue 288 asking if the new fix to hat issue 
(from fry) addresses this issue too.

Original comment by nimbus4...@gmail.com on 8 Feb 2011 at 6:33

GoogleCodeExporter commented 9 years ago
For the record, this is a workaround to put in your startup listener:

Logger.getLogger("com.google.inject.internal.util").setLevel(Level.WARNING);

Original comment by icol...@gmail.com on 8 Mar 2012 at 10:34

GoogleCodeExporter commented 9 years ago
I agree that this issue should be dealt with. The resolution suggested in 
comment 9 is not a workaround, but rather a hideout.

Original comment by hus...@guliyev.com on 24 Apr 2012 at 1:23

GoogleCodeExporter commented 9 years ago
I also think this issue should be dealt with. Also comment 9 is not a 
workaround.

Original comment by dw...@versature.com on 15 Jan 2013 at 4:09

GoogleCodeExporter commented 9 years ago
Please reopen this and treat it accordingly. If people end up reading this 
thread is for a reason. The exception is indicating an error failing to 
start... and access denied. That is not the normal info message one would 
expect to see in a log.

Original comment by Juan.Gen...@pnvillarreal.me on 15 May 2013 at 12:33

GoogleCodeExporter commented 9 years ago
Note that the FinalizableReferenceQueue message came from an old embedded copy 
of Guava which started a background thread to handle cleanup of certain 
weak/soft collections. Guice trunk now includes Guava 11.0.1 that doesn't start 
a background thread for these collections, so this message will no longer occur.

Original comment by mccu...@gmail.com on 15 May 2013 at 12:55

GoogleCodeExporter commented 9 years ago
thanks

Original comment by Juan.Gen...@pnvillarreal.me on 15 May 2013 at 12:57

GoogleCodeExporter commented 9 years ago
I'm using Guice v3.0 + Guava v12.0 the issue still occurs. And its eating CPU.
For a request it took 47306ms.

Kindly fix this. 

Original comment by sow...@gmail.com on 3 Jul 2013 at 1:45

GoogleCodeExporter commented 9 years ago
As mentioned above, Guice 3.0 embeds a local copy of Guava repackaged under a 
different package name. So adding Guava 12.0 to your classpath won't change 
anything because Guice will still use the old embedded code.

You either need to build Guice trunk locally and use that (at least until the 
next release is available), or look at 
http://search.maven.org/#artifactdetails%7Corg.sonatype.sisu%7Csisu-guice%7C3.1.
5%7Cjar which is Guice trunk plus some extra patches (these patches include 
making Guava a proper dependency rather than embedded).

Original comment by mccu...@gmail.com on 3 Jul 2013 at 1:57

GoogleCodeExporter commented 9 years ago
When is the next release available?  This is a serious problem.

Original comment by deleteda...@gmail.com on 21 Jan 2014 at 10:28