Hi John,
John Moore schrieb:
Problem: The communication via mod_jk between Apache and Tomcat appears
to suddenly become "exhausted" and cease to be available.
Please have a look at your mod_jk log file and look for '[error]'
messages. Around the error messages there should also be additional info
messages giving some mor einfo about the root cause.
Versions:
apache-tomcat-5.5.23.tar.gz
httpd-2.0.59.tar.gz
tomcat-connectors-1.2.21-src.tar.gz
managerx-5.5-1.7.2
CentOS 4.6 (final)
OK, you could switch to mod_jk 1.2.26 so we don't have to check against
any old bugs. 1.2.26 is now 3 months old and no major new bugs are known.
Symptom:
Apache suddenly reports that the "service is unavailable" when trying to
serve a context from Tomcat.
Frequency:
Generally about once a month. It also can happen quicker if ManagerX
is used with any frequency. I have about 10 different webapps running.
Restarting Tomcat does nothing, Restarting both Apache and Tomcat does
nothing.. ONLY rebooting the machine will get everything back working.
That sounds really weird. If you stop and start Apache httpd and Tomcat
(i.e. all processes completely stopped, wait a few seconds and then
started freshly), those processes should not have any more knowledge of
previous problems.
Possibly related information:
netstat -np --tcp reports dozens of "dead" connections to port 8009,
like the following samples: (count in parens to save space here):
tcp 0 0 127.0.0.1:8009
127.0.0.1:48461 SYN_RECV - (13)
tcp 0 6 127.0.0.1:48459
127.0.0.1:8009 FIN_WAIT1 - (3) tcp 6 0
::ffff:127.0.0.1:8009 ::ffff:127.0.0.1:48191 CLOSE_WAIT - (50)
The CLOSE_WAIT most likely come from the fact, that you use a
connect_timeout (that's fine) for mod_jk, but have no connectionTimeout
on teh Toncat side. Set connectionTimeout in the Tomcat sidfe in the AJP
connector to 600000 (milliseconds).
The SYN_RECV seem to indicate, that your Tomcat is not able to accept
any more connections. Two possible reasons:
- all threads in the thread pool of your AJP connector (Tomcat side) are
already connected with httpd and no more threads are left. E.g. in your
case it could be, that 50 threads are connected and maybe the size of
your thread pool is 50?
- you got an exception during creation of a new thread for the pool, and
as a consequence your Tomcat is not listening any more. Can you see the
LISTEN for 8009 in netstat? If no, the most likely cause is, that your
JVM exceeded the number of threads that it can create (most 32 Bit JVMs:
something between 400 and 500).
If the problem happens again: check to see, if you can telnet to the TC
port (telnet localhost 8009). If no, then mod_jk also has no chance of
connecting to the Tomcat and we must find out, why Tomcat doesn't accept
any more connections. In that case a thread dump of the Tomcat java
process is helpful (kill -QUIT, result goes to catalin.out).
and NO established connections even when attempting to access a service
on Tomcat
I attempted to work on various settings in the worker.properties file
under the assumption that this is the key area to try and solve the
problem based on a number of messages here and at other venues.
I'm assuming I still do not have it right, but have exhausted my
understanding of the causes..
worker.properties:
worker.list=ajp13
worker.ajp13.port=8009
worker.ajp13.host=localhost
worker.ajp13.type=ajp13
worker.ajp13.cachesize=30
Although we still respect that old name "cachesize", it got deprecated
in the meantime and since you work with Apache httpd we recommend to
drop this. The maximum connection pool size will be automatically
adjusted w.r.t. the number of threads per Apache httpd process.
worker.ajp13.socket_timeout=120
See if it helps to drop the socket_timeout.
worker.ajp13.connection_pool_timeout=600
worker.ajp13.connect_timeout=7000
worker.ajp13.prepost_timeout=7000
worker.ajp13.reply_timeout=60000
All OK.
worker.ajp13.recycle_timeout=120
Again deprecated. Replaced by connection_pool_timeout above. Remove.
See: http://tomcat.apache.org/connectors-doc/reference/workers.html
worker.ajp13.retries=3
Anyone have some suggestions as to how to solve this problem.. It is
rendering my production machines nearly useless..
>
Thank You!
John..
Regards,
Rainer
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]