Rainer Jung wrote:
Jim Jagielski schrieb:
In a nutshell, there are many cases where Apache httpd and
Tomcat are separated by a firewall, and, as such, there
isn't a one-to-one direct connection. The firewall
will close a connection but one side doesn't
know about it.
I would call this a broken firewall, right? This kind of behaviour is
expected to produce problems for nearl every communication (I don't say,
we shouldn't provide a workaround).
definitely not a broken firewall, works exactly like it should. it
silently drops, that is how it avoids making itself vulnerable to DOS
Still: do you know, what happened in the actual problem case:
- which side of the communication has been shut down by the firewall,
Apache-FW or FW-Tomcat?
- did it reset it, do a full Fin-Ack... or did it just start to silently
drop packets?
- was keep_alive anbled for the worker? This is a standard socket
option, that is used to simulate traffic on a connection. The default
settings for many OSes are interval equals 7200 seconds, so that only
onc every 2 hours a TCP keep alive packet is being sent. Depending on
the FW admins idea about idleness, it might be enough to simply lower
the keep alive interval in the OS TCP configuration. Has this been tried?
As such, new requests create more
sockets until TC runs out of threads. mod_jk is
not recycling connections as it should, and
What do you mean by "not recycling"? I think this symptom hasn't been
reported until now.
setting the various params (eg: connection_pool_timeout)
does not solve the problem. It's similar to the old
Apache http lingering close problem.
http://www.mail-archive.com/tomcat-dev@jakarta.apache.org/msg75444.html
is one example of such problems, in which case you
responded and agreed that don't reuse is a last resort
solution.
I don't find lingering close in this message. The primary situation for
this user was the need to connect a lot of Apache threads to a tomcat.
In the meantim the APR connector got more stable, so that would be the
best choice for him. If he will still run out of threads on the tomcat
side, he will need to segment his setup into smaller cells. Trying to
"solve" this kind of situation by not reusing connections is really no
solution, but a broken system design.
I just think it would be nice to provide that last
resort :)
With this I agree. There is another possible solution:
we could add another parameter to the pool sizing, the max idle count.
This would be exactly analogous to the httpd and tomcat pool semantics.
Setting it to 0 would mean, that no connection will be put back into the
pool and instead all connections are being closed after a request. Comments?
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
