I had done a stress test with 20 contemporary request to a web app using tomcat6 6bit. When maxThreads=200 tomcat gave response to only some request then went to 0 cpu time no more response, nothing on log file. This happenend only on contemporary requests (max threads reched i presume). Increasing maxThreads to 250 all request were satisfied.
Lucio 2010/7/16 Mark Thomas <ma...@apache.org> > On 16/07/2010 14:19, Luciano Fioriti wrote: > >> It may be caused by maxThreads parameter in http connector, try to >> increase >> > > On what basis are you reaching that conclusion? > > Mark > > > > >> lucio >> >> 2010/7/16 Mark Thomas<ma...@apache.org> >> >> On 16/07/2010 06:49, Matt Peterson wrote: >>> >>> While load testing our clustered Tomcats, we are seeing the following >>>> stack >>>> trace in our catalina.out occasionally, but not regularly: >>>> >>>> >>>> >>>> Jul 16, 2010 3:34:49 PM org.apache.catalina.ha.session.DeltaManager >>>> messageReceived >>>> >>>> SEVERE: Manager [localhost#/urs]: Unable to receive message through TCP >>>> channel >>>> >>>> java.lang.IllegalStateException: removeAttribute: Session already >>>> invalidated >>>> >>>> >>> <snip/> >>> >>> >>> Under what conditions would this occur? Could it be that a session diff >>> is >>> >>>> being transmitted, but the session it relates to has been invalidated by >>>> the >>>> time the diff is processed (via a user logout for example)? Or could it >>>> be >>>> that a timeout has been reached??? >>>> >>>> >>> Someone at $work has been doing a load test with tc Server (which has >>> identical code to Tomcat in this area) and seen the same issue. I know it >>> isn't due to timeout since the sessions are only a few seconds old when >>> it >>> happens. My current guess is that the messages are not being processed in >>> the same order as they are sent. I need to dig into this more to figure >>> out >>> if this is a configuration issue or a bug. >>> >>> I did wonder if switching to channel send options 6 would fix it. I'll >>> get >>> them to try that and see. >>> >>> Mark >>> >>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >>> For additional commands, e-mail: users-h...@tomcat.apache.org >>> >>> >>> >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
