Leon Rosenberg wrote:
Hello Andre, et al,
On Wed, Feb 6, 2013 at 2:40 PM, André Warnier <a...@ice-sa.com> wrote:
Leon Rosenberg wrote:
...
We have 105 threads in this state over multiple hours.
Question: Could it be that we have connection leakage through keep-alive
connections? Is there are possibility to reduce them?
I understand that jboss have the same apache 11 connector, however all
extended configuration options are removed from the doc:
http://docs.jboss.org/**jbossweb/7.0.x/config/http.**html<http://docs.jboss.org/jbossweb/7.0.x/config/http.html>
I don't know Jboss at all, but assuming that it is Tomcat behind, and
assuming that they have not replaced the HTTP Connector by their own, then
their documentation is wrong, and you could try the following attributes :
keepAliveTimeout
The number of milliseconds this Connector will wait for another HTTP
request before closing the connection. The default value is to use the
value that has been set for the connectionTimeout attribute. Use a value of
-1 to indicate no (i.e. infinite) timeout.
connectionTimeout
The number of milliseconds this Connector will wait, after accepting a
connection, for the request URI line to be presented. Use a value of -1 to
indicate no (i.e. infinite) timeout. The default value is 60000 (i.e. 60
seconds) but note that the standard server.xml that ships with Tomcat sets
this to 20000 (i.e. 20 seconds).
connectionTimeout can play a role if there are (nefarious) clients which
establish a connection to your server, but then just hang there and never
send any request on that connection. That's one known form of DOS attack.
A keepAliveTimeout of 60 seconds seems quite high to me. It means that
- the browser created a connection and asked for it to be "persistent"
- the browser sent a request on this connection
- the server allocated one thread to process that request
- the thread sent the response to that request
- now the thread, instead of being immediately released to the pool of
idle threads (to process some other request) hangs on to the connection,
waiting to see if the browser has another request to send on it. And it
hangs so for keepAliveTimeout time (60 seconds here in the default case).
- if another request comes within a short period of time, the benefit is
that the connection has not been closed, so the browser and server do not
have the overhead of establishing a new one (a few packets exchanged, a few
thousand lines of code ran).
But if the browser has no more requests to send right now, you are wasting
an open TCP connection and a thread sitting there just waiting.
I can see this as useful nowadays if your application serves a lot of
pages containing many embedded <img> tags or the like, since the browser
will not have to open a new connection for each image that it wants to
retrieve.
But even then, a few seconds of keepAlive would suffice.
My analysis is pretty near yours. Still I don't think we are DOSed somehow,
but some 3K concurrent sessions could indeed block few hundred of threads
by simply keeping their browsers open and doing nothing.
I will try to reduce keep alive settings just to be sure :-) I hope Jboss
submits the parameter one on one ;-)
I am far from an expert in the matter, but JMX should allow you to view whatever
parameters are in effect in the end. That's at the JVM level, so it should be independent
of JBoss.
Also, don't know if it is your case, but if you are using Windows Integrated
Authentication, setting keepAlive very low may have detrimental effects, forcing WIA to
re-authenticate the user sessions more frequently.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
