* I see that the requests processors increase but it does not stop the stuck * The data base is slow on get connection but i checked the connections and i still have many left that can be used * i see that the active threads count get to the limit before the stuck (according to jconsole) but after the stuck it goes down to 0 back again and it is still stuck so i don't believe the problem is no threads available for work * as for the stream requests: i use jmeter to create soap requests. i saw that it uses org.apache.commons.httpclient.methods.RequestEntity to write the requests as streams. when i use the jmeter to send after tomcat stops processing requests, it does not get the request when i use my own simulator which writes a regular string using http client - the tomcat does receive the request
Caldarale, Charles R wrote: > >> From: Michal Singer [mailto:[EMAIL PROTECTED] >> Subject: RE: tomcat gets stuck after a load for streams writing >> >> i configured the maxThreads on the executor and didn't help. > > It should have let you get to 400 request processors, rather than the > default of 200 that you were seeing. > >> i also checked the thread dumps. > > And where do they show the threads are? If you can force the hang with > any number of threads, then set maxThreads to a low value, and see where > they are executing when the stall occurs; things will be easier to figure > out when there's less to look at. > >> i still don't understand why it would cause >> a completey unrecovable tomcat stuck. > > If all the possible threads are already working on requests, no more > requests will be honored. You could also be out of data base connections > (assuming you are using one), resulting in all threads waiting until a > connection becomes available. If you webapp fails to return connections > to the pool in *all* circumstances, eventually you'll hang. > >> What also is weird is that it gets stuck only for stream >> writing. this does not seem like a problem in our server. >> why can i still send string messages? > > I don't know what you mean by "stream writing" vs "string messages". If > these are actions performed by the client you're using to test Tomcat > with, it's irrelevant how the requests are constructed on the client end - > it's all HTTP by the time it comes over the wire. If one of the > mechanisms is passing in bad headers, that's a different matter. An > improperly terminated chunked request could tie up a thread for quite some > time. > > - Chuck > > > THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY > MATERIAL and is thus for use only by the intended recipient. If you > received this in error, please contact the sender and delete the e-mail > and its attachments from all computers. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- View this message in context: http://www.nabble.com/tomcat-gets-stuck-after-a-load-for-streams-writing-tp20878338p20890106.html Sent from the Tomcat - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
