Hi, I'm not sure whether this could be of any help, we had a similar problem and created a javacore and found a real basic locking in java output stream. The reason were concurrent System.out.println() in different threads for different requests which blocked the real stdout (some jsp's with some console output for checks). It was not a Tomcat application, but a wep app in bea (aix, 2 Processors), but it was really a problem in java, so could be the same. After removal of all System.out/err calls the error disappeared - obvious because reason was identified in core file.
Sascha > -----Ursprüngliche Nachricht----- > Von: Martin Schulz [mailto:[EMAIL PROTECTED] > Gesendet: Donnerstag, 24. Juni 2004 00:37 > An: Tomcat Developers List > Betreff: Re: Any synchronization issues with SMP? > > > Rainer, > > Thanks for the tips. I am about to take timing stats > internally in the ThreadPool and the Tcp workers. > Also, the described symptoms do not disappear, but seem to be of much > shorter duration when only 4 CPUs are used for the application. > I'll summarize what I find. > > Martin > > Rainer Jung wrote: > > > Hi, > > > > we know one application running on 9 systems with 4 US II CPUs each > > under Solaris 9. Peak request rates at 20 requests/second per system. > > Tomcat is 4.1.29, Java is 1.3.1_09. No symptoms like yours! > > > > You should send a signal "QUIT" to the jvm process during the > > unresponsiveness time. This is a general JVM mechanism (at least for sun > > JVMs). The signal writes a stack trace for each thread on STDOUT (so you > > should also start tomcat with redirection of STDOUT the output to some > > file). Beware: older JVM in rare cases stopped working after getting > > this signal (not expected with 1.3.1_09). > > > > In this stack dump you should be able to figure out, in which methods > > most of your threads stay and what the status is. > > > > Is there native code included (via JNI)? Any synchronization done in the > > application itself? Are you using Tomcat clustering? Which JVM? > > > > Sincerely > > > > Rainer Jung > > > > Martin Schulz wrote: > > > >> Can someone confirm that Tomcat works well on busy SMP systems (e.g. > >> Sun V1280), > >> or whether there are problems in Tomcat. > >> > >> Here's what we have at our end: > >> > >> We are currently performance testing our application (Tomcat 4.1.30) > >> on Solaris 9, > >> on a V1280 system w. 8 CPUs. (SDK 1.4.2_04). Transaction rates are > >> moderate, around 30/s. > >> > >> The application, after about 30-40 minutes, gets unresponsive for a > >> little while (1-10 minutes), > >> gets back to work (for a varying period of time, but definitely under > >> 30 min), and then the cycle > >> repeats. At half the transaction rate, the smptoms are no longer > >> easily observed,. > >> > >> The above symptoms disappear when we use a single CPU, or a single > >> board of 4 CPUs. > >> That scenario seems to imply synchronization problems soemwhere in > >> the Java code. > >> The problem could not be observed in development configurations > >> either (Wintel, 1-CPU Sun > >> boxes.) > >> > >> The behavior is such that connections get accepted, but no response > >> is sent (established connections > >> remain at a fixed level). The number of connections in this state > >> varies (20-70). > >> > >> From the timers we keep we learn that the service gets stuck when > >> reading the input. > >> Once unblocked the responses get sent out rapidly again. > >> > >> We have tuned the system for efficient, high-volume TCP-IP traffic. > >> > >> We tried the coyote connector and the HttpConnector, both with the > >> same effect. > >> > >> Please respond if you can confirm or dismiss threading issues > in Tomcat. > >> We would also be ineterested in testing approaches for such a scenario. > >> > >> .I have kept system statistics for both scenarios and can provide > >> these on request. > >> > >> Thanks! > >> Martin Schulz > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
