Hi Leon,
Recently I've noticed similar deadlocks on my tomcat server. In my case,
the server just hangs with no warning even though there is plenty of
memory available. I tried the following to locate the problem, but it
has all been in vain:
* upgrade jdk from 1.5.0.1 to 1.5.0.6
*
behaviour or an indication for a deadlock. What I can say,
is that the 2.4.x kernel could be a problem if you have more then 800
threads.
Do you have NPTL or the standart linux threading? I don't know your
linux distro, but most 2.4.x kernels came out without NPTL support, is
updating to 2.6.x
Leon Rosenberg wrote:
This is called thread hi-jacking :-)
Sorry, thought it might be the same issue.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
I've studied a number of stack traces and the locking seems fine - there
is evidence of cyclical deadlock. The problem is that a whole lot of
threads (including the ones holding the locks) are listed as 'waiting
for monitor' but I can't see why.
I found out that it was the garbage collector
Hi there,
I first ran into bug 39627 [1] when trying to get my logging working
properly and got to have a pretty thorough read of the JULI code. I
noticed that the readConfiguration(stream) method doesn't reset the
configuration properly. It just calls a super.reset(), but the
superclass does
Hi there,
I'm running tc-5.5.16 and am having a problem with certain clients
consuming large numbers of ajp threads which are never released. I can
see from the httpd logs that these clients are all Windows machines and
each thread is being used to return a 16-64Kb portion of the files they
a
Ondrej Zizka wrote:
Hello,
I have the common problem with PermGen and Tomcat, see
http://mail-archives.apache.org/mod_mbox/tomcat-users/200606.mbox/[EMAIL
PROTECTED]
Suppose there is a school server where students (re)deploy their apps, each
of which's classes definitions take about five to t
The following configuration gives me a javax.naming.NameNotFoundException:
However, if I move the JNDI resource up it works as expected:
...
Is that the intended behaviour?
Cheers,
Roger
---
