Craig,

        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).
HttpConnector.java 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.


Kumar.


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




On Sat, 7 Jul 2001 [EMAIL PROTECTED] 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
everyone.

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

Craig

Reply via email to