André Vila Cova wrote:
Red Hat Enterprise Linux AS release 4 (Nahant Update 5)

Release............ :  Jakarta-Tomcat 5.5.20

Modulo nativo APR:  tomcat-connectors-1.2.20

JVM versão..... : Sun JVM1.5.0_11

I think that apache web server don't receive response from tomcat and don't
send final ack to tomcat and tomcat don't free threads.I see every logs from
oracle executions and duration of TOP SQL is very low.
I made test using the same architecture without firewall and everything
works fine. Tomcat free threads and send complete response to web server.

If your analysis is correct, it's a known problem, that firewalls often drop idle connections, so mod_jk and Tomcat should both be configured to shut down idle connections. On the Tomcat side you should use the attribute connectionTimeout in the configuration of your AJP Connector in server.xml. The units are in milliseconds, so 10 Minutes would be 600000. On the mod_jk side you should use connection_pool_timeout, units are seconds, so 10 minutes are 600.

We have a new docs page about these things, which will go live next week with our 1.2.24 release. There is a preview for the page under

http://people.apache.org/~rjung/mod_jk-dev/docs/generic_howto/timeouts.html

The next release 1.2.24 will some improvements for this situation, but you would still need the timeouts on bith ends.

For a plausibility check, if this really is your problem, you could compare "netstat -an" (only the lines corresponding to your Tomcat AJP port) on the Apache and on the Tomcat side, and also check with the JVM Thread Dump (kill -QUIT to Tomcat; it will not die, but write a list of all threads with a stack for each of them to catalina.out). If the firewall dropped the connections, most likely the two netstat outputs will show an inconsistent state for the connections. Tomcat threads, which sit listening on an idle connection will be shown in the thread dump as reading from the socket.

Regards,

Rainer

Thanks.



On 7/26/07, Rainer Jung <[EMAIL PROTECTED]> wrote:

Hi,

you didn't give us your versions, you platform or any configuration info.

André Vila Cova wrote:
> Hello!
>
> Apache mod_jk returns following error (frequently...):
>
> [Thu Jul 26 11:07:52 2007] [2703:1120] [error]
> ajp_connection_tcp_get_message::jk_ajp_common.c (948): (app02_aol) can't
> receive the response message from tomcat, network problems or tomcat is
> down
> (192.168.40.11:8007), err=-104
> [Thu Jul 26 11:07:52 2007] [2703:1120] [error]
> ajp_get_reply::jk_ajp_common.c (1566): (app02_aol) Tomcat is down or
> refused
> connection. No response has been sent to the client (yet)
>

The 104 is the errno of your local platform. For Linux 104 is
"Connection reset by peer".

> We have two firewalls between Apache Web Server and Tomcat Web , but we
> didn't see nothing wrong in firewalls logs.

> Response appear on browser, but seems that no ack flag arrives to
webserver
> to finish request. Tomcat crashs with error All threads (400) are
currently
> *busy*, waiting. Increase *maxThreads* (400) or check the servlet
status.

The above log entry is for only a single request. You write that the
response actually goes back to the browser, but I guess you mean "most
of the requests", or are you sure that this single request produced a
response?

No idea, what you mean by "crash"? If this message appears, it means,
that all the threads you have configured in you thread pool of the
tomcat connector are busy by running a request. Since you configured 400
threads max, this might actually mean, that something is to slow in your
app or in some backend your app is using, so the requests take to long
and the system becomes congested. In this situation take a java thread
dump to check, what those 400 threads are actually doing.

> Is it a configuration problem? May I setup some parameter to resolve
> problem?

If only we knew your configuration ...

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