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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
