I would agree, that 65 is a very low thread limit for a J2EE web
container, at least if it will get serious load. Java Enterprise gets
its performance out of concurrency.
Your observation, that you actually run out of threads already proves
you, that you will need more than 65 threads.
So I would also first try to push the limit upwards to a couple of
hundreds of threads. That should be no problem at all for modern
operating systems.
If you want to learn, how man extra threads there are, send your tomcat
process a kill -QUIT and have a look at catalina.out. The QUIT signal
lets the JVM write a thread dump to the ouput, which gets redirected to
catalina.out by the standard tomcat startup script.
The thread dump contains a block of text for each thread in the JVM. The
Threads belonging to an AJP connector will be named TP-Processor, the
ones for the HTTP(S)-Connectors will have the ports in their names. The
other additional threads also partially depend on the number of contexts
you deployed. Look at their names.
The question about Tomcat serving no more requests, once you reached the
OS thread limit: if a new request comes in, the listening thread serves
the request and a new thread is taken out of the pool to do the next
accept on the port. If the pool is empty, it will try o create new
threads for this task. If this fails, there will be no more thread
listening on the connector port, so your tomcat is not reachable any more.
Regards,
Rainer
David Delbecq wrote:
Just for information,
we run tomcat on HP-UX with no special tomcat limitation on max thread.
We also use a NIS (aka Yellow pages) based JNDI authentification. We sun
the sun provided NIS context for jndi. This tool is known by us to
create something around 200+ temporary threads to get it's datas (yes
awful!). We never hit a maximum Thread limit from the OS. Maybe it will
be easier to ask the server admin to increase the max threads per
process to something like 2000+ which is more reasonnable for a server imho.
Another solution could be to use green threads (JVM handled threads and
task switching as opposed to OS handled threads and task switching) if
they are available on your JVM....
En l'instant précis du 10/08/07 09:40, pkt s'exprimait en ces termes:
i tried to do that but still the thread count goes beyond 45-50. so i guess
with some more load it will go beyond 65. And yes the figure is total of jvm
and tomcat. But is there any way to restrict this to not exceed 65.
Leon Rosenberg-3 wrote:
you not counting the threads which are used by jvm and tomcat itself,
and those are more than 5.
Try with max threads = 25 and check whether this works at all on your
machine.
regards
Leon
On 8/10/07, pkt <[EMAIL PROTECTED]> wrote:
HI All
I and running tomcat on HPUX machine. The problem is that on HP machine
the maximum thread per process allowed is 65 ( default), so i configured
max
thread count in server.xml to 60. I used JMeter to check the behavior
when
there is enough load on tomcat. What i have observed is that even though
i
configured its maxthread count not to exceed 60 it is reaching 65 and as
soon as it goes beyond 65 tomcat throws OutOfMemoryError. After this the
thread are killed ( probably by the OS) and then the thread count comes
back
to around 27 but tomcat does not process any new request any more. What i
was expecting is that once the threads are killed and thread count comes
back to 27 it should again start processing new request.
One option is that to increase the max thread per process limit of HP to
high value, but administrators are not very convinced with this idea
Any pointers on this issue.
Thanks and Regards
Pankaj Tiwari
--
View this message in context:
http://www.nabble.com/Tomcat-Issue-with-HPUX-tf4246754.html#a12085566
Sent from the Tomcat - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
