Re: "Too Busy" Error Needed

Marc VanHeyningen <mvanheyn@cs.indiana.edu>
Errors-To: listmaster@www0.cern.ch
Date: Thu, 9 Jun 1994 02:00:58 +0200
Errors-To: listmaster@www0.cern.ch
Message-id: <16342.771119924@silky.cs.indiana.edu>
Errors-To: listmaster@www0.cern.ch
Reply-To: mvanheyn@cs.indiana.edu
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: Marc VanHeyningen <mvanheyn@cs.indiana.edu>
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: Re: "Too Busy" Error Needed 
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
X-Mailer: exmh version 1.4delta 6/3/94
X-Mailer: exmh version 1.4delta 6/3/94
> There are situations when an HTTP server may want to indicate that it is too 
> busy to accept a request. There is no code for this defined in the HTTP2 
spec. 
> Taking the "spirit" of the 400 vs 500 errors, since this is a server 
> "problem", it seems like the 500 series is appropriate.

Sounds reasonable.

> The Windows httpd (v1.2b8 and later) reports when it is too busy to accept 
> another request by returning a "503 Too Busy", followed by a short HTML 
> message. What it means is that there are already 8 active transactions, the 
> server's limit. The error is returned in the server dispatcher thread 
without 
> starting any new transaction threads.

How long is the average transaction active?  I'd guess a second or two, tops.
If you think it's necessary to define a hard upper limit on number of
simultaneous transactions, it would be much preferable to try to just block
and wait for an existing transaction to terminate if that's possible, subject
to some sort of timeout error of course.

Having to wait a couple seconds instead of having to keep retrying makes
for much less overhead for the server, the network, the client and the user.