tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Hanik - Dev Lists <devli...@hanik.com>
Subject Re: possible mod_jk "feature"
Date Wed, 23 Aug 2006 14:06:55 GMT
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: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>     
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
>   


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message