Salut,
switching mailing list
glassfish_at_javadesktop.org wrote:
> 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:
Can you share what your ProtocolFilter implementation is doing exactly?
Or are you using the http extension?
>
> 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?
The application that was using Grizzly caused this issue. So it was
*not* an issue with Grizzly.
We were thinking of updating to grizzly 1.9.x, but if the root cause is
with the Sun implementation of SocketChannels,
There is no issue with SocketChannel as far as I know.
I don't know if that'll help, plus we'd have to refactor some to remove
some deprecated classes.
Let's try to first see if we can found the issue with 1.8.6 so you don't
have to update yet.
Any help or thoughts would be very much appreciated.
Can you comes with a test case? Let's continue the discussion using
users_at_grizzly.dev.java.net
Thanks
-- Jeanfrancois
> [Message sent by forum member 'mnovakouski' (mnovakouski)]
>
> http://forums.java.net/jive/thread.jspa?messageID=342902
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>