The important threads to look at are the httpSSLWorkerThread-8080 --
those are the threads that handle the HTTP requests. In your case, all
of those threads are blocked waiting for a response from some remote
HTTP server. That server is apparently slow, tying up all the HTTP
threads in your appserver.
You can add some additional request processing threads for your HTTP
service, but that's likely only to make things worse; more requests to
your remote system are likely to make that system even slower. You
need to find a way to make that remote system's HTTP requests faster.
-Scott
On May 8, 2008, at 5:31 AM, Kristian Rink wrote:
> Folks;
>
> Am Wed, 07 May 2008 03:04:50 PDT
> schrieb glassfish_at_javadesktop.org:
>
>
>> Maybe you should do "asadmin generate-thread-report --type=thread >
>> threaddump.txt" before you restart the domain. Then you can see which
>> threads are locked and what they are waiting for.
>
> So I managed to set up a load-reduced testbed environment in our
> system, trying to reproduce the error. Took longer than the days
> before, but it finally happened again. Upgrade to v2u2 before that,
> just to be sure. However the output of generate-jvm-report
> --type=threads can be found at
>
> http://zimmer428.net/zeugs/threads.txt
>
>
> ... for what I see there indeed is a bunch of threads "waiting on
> lock", but I am not sure I correctly understand why this happens. Does
> anyone out here have better ideas?
>
> Thanks in advance and kind regards,
> Kristian
>
> --
> Kristian Rink * http://zimmer428.net * http://flickr.com/photos/z428/
> jab: kawazu_at_jabber.ccc.de * icq: 48874445 * fon: ++49 176 2447 2771
> "One dreaming alone, it will be only a dream; many dreaming together
> is the beginning of a new reality." (Hundertwasser)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>