Salut,
glassfish_at_javadesktop.org wrote:
> In my original post at the top of this thread I noted that the server _instantly_ (no time for the domain to stop/start) comes back to life if I fiddle with a setting in the HTTP Service section of the admin console. So, what happens when such settings are changed? What is it about saving a settings change in Glassfish that could explain this? What gets replaced or flushed or reset?
> [Message sent by forum member 'kevinmacdonald' (kevinmacdonald)]
I've missed that...the http-listener is restarted, unlocking all the
thread. If you can reproduce the problem easily, next time it happens
try to do a jstack PID (or use the admin gui to generate a jvm report).
You seems to have the same issue than Ryan, which is all thread are in
use and request are queued...since the max queue size is 4096 and your
default ulimit was 1024, that explain the exception you were getting ;-)
If you try again with GlassFish I suspect that exception will no longer
happens, but request processing will be quite slow as all threads will
have to process 4096 queued requests.
We need to find why your request are queued. Like I said, it's usually
not a Grizzly/WebContainer issue. You can reproduce that issue easily by
writing a Servlet that does:
Thread.sleep(60000);
Do 10 requests, and you will get the same unresponsiveness as you has
been observed. All requests will be serviced, but the last 4 will take a
while.
Thanks
-- Jeanfrancois
>
> http://forums.java.net/jive/thread.jspa?messageID=272417
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>