tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject RE: Question on HTTPConnector.
Date Sun, 08 Jul 2001 03:49:31 GMT

	Thanks for clarification. I do agree with you given the three options the one choosen by
tomcat group is the best one(Option one).
	But there need to be an option for tomcat users to use option 3 in case where DOS issues
are solved by some other means (ex: using a switch which does the same). has following lines:
     * The maximum number of processors allowed, or <0 for unlimited.
    private int maxProcessors = 20;

Which gives an impression if maxProcessors  is set to a -ve value in server.xml unlimited
option is used. But this is not implemented. 
A way to test this is set minProcessors="0" maxProcessors="-1". You will notice that server
is not responding for request.


-----Original Message-----
From: Craig R. McClanahan []
Sent: Saturday, July 07, 2001 5:45 PM
Subject: Re: Question on HTTPConnector.

On Sat, 7 Jul 2001 wrote:

> Looking at org.apache.catalina.connector.http.HTTPConnector I got a
> question regarding the way its implemented.(I am looking at 4.0b3 src)
> Look at this block of code(in run method of HTTPConnector):
> 	    // Hand this socket off to an appropriate processor
> 	    HttpProcessor processor = createProcessor();
> 	    if (processor == null) {
> 		try {
> 		    log(sm.getString("httpConnector.noProcessor"));
> 		    socket.close();
> 		} catch (IOException e) {
> 		    ;
> 		}
> 		continue;
> 	    }
> As per my understanding if no. of HTTPConnections == maxProcessors(
> parameter in server.xml), when a new HTTPRequest comes server just
> closes the Socket with any wait period.

Yes, that's exactly what happens.

> Isn't this Bad? In cases where
> Load suddenly increases this could cause problems.

Well yes, it's bad, but so will any other reaction.  What choices are
there in handling it?

(1) Current behavior of closing the connection and go back to
    accepting new connections (causes a client-side protocol error)

(2) Pause and try again in a bit (but in the mean time, this
    thread cannot accept any new connections, so they stack up
    inside the server socket up to acceptCount and then start
    getting refused)

(3) Ignore the maxProcessors parameter and create a new processor (and
    its associated thread) anyway (can lead to denial of service attacks)

Have you a suggestion on how we might deal with this more effectively?

The real key is to configure maxProcessors to the maximum number of
simultaneous requests you want your server to handle, based on the
hardware capabilities and the processing requirements of your
application.  For example, if your response time starts going through the
roof once you exceed N simultaneous requests (because you've encountered
some sort of bottleneck), it doesn't make sense to set maxProcessors
higher than N -- that will just cause response times to slow down for

> Any info on this is greatly appreciated.
> Thanks,
> Kumar.


View raw message