Hello all,
I am new to grizzly, and my company is attempting to use it to run a server using java 1.6. We are using Grizzly 1.8.6. The problem is that while running an endurance test, we found that after roughly the same number of connections (~1000) the server locks up and spews the following stack trace to the log file over & over until the disk fills:
java.lang.InternalError
at sun.misc.URLClassPath$JarLoader.getResource(Unknown Source)
at sun.misc.URLClassPath.getResource(Unknown Source)
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at sun.misc.Launcher$ExtClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.util.ResourceBundle$RBClassLoader.loadClass(Unknown Source)
at java.util.ResourceBundle$Control.newBundle(Unknown Source)
at java.util.ResourceBundle.loadBundle(Unknown Source)
at java.util.ResourceBundle.findBundle(Unknown Source)
at java.util.ResourceBundle.findBundle(Unknown Source)
at java.util.ResourceBundle.getBundleImpl(Unknown Source)
at java.util.ResourceBundle.getBundle(Unknown Source)
at java.util.logging.Level.getLocalizedName(Unknown Source)
at java.util.logging.SimpleFormatter.format(Unknown Source)
at java.util.logging.StreamHandler.publish(Unknown Source)
at java.util.logging.ConsoleHandler.publish(Unknown Source)
at java.util.logging.Logger.log(Unknown Source)
at java.util.logging.Logger.doLog(Unknown Source)
at java.util.logging.Logger.log(Unknown Source)
at com.sun.grizzly.Controller.doSelect(Controller.java:494)
at com.sun.grizzly.SelectorHandlerRunner.run(SelectorHandlerRunner.java:82)
at com.sun.grizzly.Controller.startSelectorHandlerRunner(Controller.java:1136)
at com.sun.grizzly.Controller.start(Controller.java:943)
at com.x.core.y.controller.xServer$1.run(xServer.java:51)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.util.zip.ZipException: error in opening zip file
at java.util.zip.ZipFile.open(Native Method)
at java.util.zip.ZipFile.<init>(Unknown Source)
at java.util.jar.JarFile.<init>(Unknown Source)
at java.util.jar.JarFile.<init>(Unknown Source)
at sun.misc.URLClassPath$JarLoader.getJarFile(Unknown Source)
at sun.misc.URLClassPath$JarLoader.access$600(Unknown Source)
at sun.misc.URLClassPath$JarLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at sun.misc.URLClassPath$JarLoader.ensureOpen(Unknown Source)
... 32 more
Doing some basic google searching, this seems to be the same issue found here:
http://markmail.org/message/pjhdgk577ibklp7a#query:grizzly%20file%20descriptor%20leak+page:1+mid:czbn66uhitjzkdyd+state:results
The links embedded in the above-linked discussion seem to imply that the issue was resolved, but the following 2 links seem to imply that the issue is a file descriptor leak inherent to the sun implementation of SocketChannels, which I believe grizzly is using:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6215050
http://forums.java.net/jive/thread.jspa?messageID=342736&tstart=0
My question is, can anyone confirm what the problem is? We were thinking of updating to grizzly 1.9.x, but if the root cause is with the Sun implementation of SocketChannels, I don't know if that'll help, plus we'd have to refactor some to remove some deprecated classes. Any help or thoughts would be very much appreciated.
[Message sent by forum member 'mnovakouski' (mnovakouski)]
http://forums.java.net/jive/thread.jspa?messageID=342902