DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19799>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19799 Tomcat dies after being up for a while (complains about maxThreads) [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|INVALID | ------- Additional Comments From [EMAIL PROTECTED] 2003-08-13 01:33 ------- The load program mentioned earlier by someone else is quite valid when you think in a SOAP context. Same problem here with tc-4.1.24 and tc-4.1.27 (i did not try 5.0.x), jdk-1.4.2, RH8.0, using SOAP-like messages over persistent HTTP1.1 connections, no matter which client http library I use (commons-httpclient, innovation httpclient). The SOAP-like client and server exchange MANY (perhaps tens of thousands) serial messages over the same persistent connection (there is only one client in this test, so scalability should be straightforward),and around 74 or 75 messages TC hangs, with luck it will recover after some tens of secs, to allow one more message, then hang for some more tens of secs to allow for some 20 more messages, then hang forever (with close to 100% CPU). > - increase the processor count to a higher value is not an option with ten thousand serial messages > - decrease the connection timeout makes no noticable difference - set the maxKeepAliveRequests attribute to "1" on the connector, which will > disable connection keepalive (that hurts performance a lot) Makes no difference either!? As an aside, I noticed that the AXIS folks disabled persistent connections in their client API, perhaps for some related reason... --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
