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 16:57:36 GMT
having mod_jk rely on the AJP packet from Tomcat to close a socket or 
not, is like saying the IE browser can't close the socket unless Apache 
httpd says so.
The patch the Jim provided, gives us the functionality of turning off 
the keep alive from the "clients" (httpd in this case) perspective.

Filip

Rainer Jung wrote:
> Hi Mladen,
>
> Mladen Turk schrieb:
>   
>> Rainer Jung wrote:
>>     
>>> I still don't have a consistent idea what happened around the firewall:
>>>
>>>       
>> It is a very simple:
>>     
>
> I don't think so, because no one was able to give the details. From a
> "simple" perspective everything is clear, but only the details will give
> an indication, what the correct way to respond is. See the mail by Klaus
> Wagner and my response.
>
>   
>> 1. There are firewalls that will cut the connection
>>    between mod_jk and Tomcat without sending FIN.
>>    You can not do anything with that, cause they
>>    simply exist, and I don't care why they exist.
>>     
>
> I don't care too, but the fact, that they don't send a FIN is important.
> Thanks.
>
>   
>> 2. Only the Tomcat is affected cause mod_jk connects
>>    to it. With mod_jk if write() fails we reconnect,
>>    but Tomcat still waits on stream read() and
>>    disconnects on some systems after 240 secs,
>>    thus rising the thread count.
>>     
>
> Correct, in that case, no one shut down the connection. In case the
> correction shuts down cleanly, I found no indication, that this will
> still cause a problem on the tomcat side.
>
>   
>> 3. Up to 1.2.18 even the httpd restart could cause
>>    thread count to double in size.
>>     
>
> OK, late thanks for your fix!
>
>   
>> So, having that, the only solution is to:
>>     
>
> 0. Configure your TCP stack according to the idle timeout restrictions
> your network admins place on your network environment (TCP keepalive
> interval)
>
> or
>
>   
>> 1. Set connectionTimeout in Tomcat that will always
>>    close the inactive connections
>> 2. Use CPING/CPONG to detect disconnected sockets
>>    prior sending request.
>> Now, the advanced thing should set the reuse flag to
>> false according to the maxKeepAliveRequests in returned
>> AJP packet. This will cause both Keep-Alive to work
>> and graceful socket disconnection because both sides
>> will be closed.
>>
>>     
>>> - 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
>>>
>>>       
>> We have that already in 1.2.18.
>>     
>
> No: I'm talking about max_idle, min_idle and max_connection. We have
> connection_pool_size and conection_pool_minsize. They map as follows:
>
> Compatibility situation:
> min_idle=connection_pool_minsize
> max_idle=max_connection=connection_pool_maxsize
>
> But by giving max_connection a bigger value than max_idle, we would
> allow additional connections in case the pool is exhausted, which will
> not be pooled after end of their usage.
>
> A special case would be minIdle=max_idle=0 and
> max_connection=num_of_threads, which will lead to unpooled connections,
> i.e. each connection will be destroyed after use.
>
> The model is totally analogous to the httpd process model (maximum
> processes and min and max spare processes) and to the tomcat thread
> model for connection pools and thus should sound familiar to the users.
>
> The connctions in the pool are those that are counted as idle.
>
>   
>> Regards,
>> Mladen.
>>     
>
>
> ---------------------------------------------------------------------
> 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