tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <>
Subject Re: possible mod_jk "feature"
Date Wed, 23 Aug 2006 15:08:55 GMT
I still don't have a consistent idea what happened around the firewall:

- silently dropping is not expected apart from a deny rule, but deny
will not be the rule that had been applied to the apache-tomcat connection.

- only shutting down one side of an established (!) connection seems broken

- no answers yet about using TCP keep-alive

- no comments on my suggestion to make the connection pool more
flexible: min pool size, max pool size and max connection number? this
will allow us to

  - temporarily connect although the pool is expired with a defined limit
  - configure for not reusing connections by setting max_idle to 0

I would find out, whether it's easy to do over the weekend, but I would
like to get some feedback on the idea.

- Anyone who can reproduce a real problem, when mod_jk shuts down a
connection? I reported, that with a recent mod_jk and TC 5.5.17 on
Solaris it's not a problem, and the TC code and the Java API doc suggest
it's no problem on any platform.



Filip Hanik - Dev Lists schrieb:
> 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.
>>> 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:
>>> For additional commands, e-mail:
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message