6.0.18
tons of bug fixes (and security)
Filip
Michal Singer wrote:
* 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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
