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]

Reply via email to