did you get Grizzly from this URL?
http://download.java.net/maven/2/com/sun/grizzly/bundles/
also which connector are you using and how are you creating this connector?
the examples I see are
org.apache.catalina.Connector connector=
com.sun.jbi.httpsoapbc.embedded.GrizzlyEmbeddedWebContainer.createConnector(address,port,protocol);
BCCoyoteConnector bcCon=(BCCoyoteConnector) connector;
//do a check for bcCon null
//do a check for bcCon instanceof
//com.sun.jbi.httpsoapbc.embedded.BCCoyoteConnector.class
org.apache.coyote.Adapter adapter=new GrizzlyRequestProcessor(bcCon)
bcCon.setAdapter(adapter);
protocolHandler = new com.sun.enterprise.web.connector.grizzly.GrizzlyHttpProtocol();
bcCon.setProtocolHandler(protocolHandler);
bcCon.setMaxReadWorkerThreads(3);
bcCon.start();
code comes from arcands documentation at
http//weblogs.java.net/blog/jfarcand/archive/2006_BOF0520.pdf
does this conform to your startup code?
Martin
______________________________________________
Disclaimer and Confidentiality/Verzicht und Vertraulichkeitanmerkung / Note de déni et de confidentialité
This message is confidential. If you should not be the intended receiver, then we ask politely to report. Each unauthorized forwarding or manufacturing of a copy is inadmissible. This message serves only for the exchange of information and has no legal binding effect. Due to the easy manipulation of emails we cannot take responsibility over the the contents.
Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni.
> Date: Mon, 20 Apr 2009 17:53:21 -0400
> From: Jeanfrancois.Arcand_at_Sun.COM
> To: users_at_glassfish.dev.java.net; users_at_grizzly.dev.java.net
> Subject: Re: Having trouble with ZipException/File Descriptor leak in Grizzly
>
> 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
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>
_________________________________________________________________
Windows Live™: Life without walls.
http://windowslive.com/explore?ocid=TXT_TAGLM_WL_allup_1b_explore_042009