Re: "Too Busy" Error Needed

• Mail folder: WWW Talk Apr 94-present
• Next message: Mary Morris: "Restricting Access"
• Previous message: Chris Lilley, Computer Graphics Unit: "Re: Including files"
• Maybe in reply to: Roy T. Fielding: "Re: "Too Busy" Error Needed "

Errors-To: listmaster@www0.cern.ch
Date: Fri, 10 Jun 1994 01:22:34 +0200
Errors-To: listmaster@www0.cern.ch
Message-id: <21924.771203743@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

> Marc --
> 
> > From: Marc VanHeyningen <mvanheyn@cs.indiana.edu>
> >
> > How long is the average transaction active?  I'd guess a second or two, 
tops.
> 
> Depends on how the server is connected to the net. My vision is to have
> this server used on lots of personal machines running Windows, probably
> tied in via PPP/SLIP connections. At least till ISDN gets past the
> chicken-and-egg stage. Years, in other words. Connections could be more
> like 10 seconds and up.

Hmmm... I would question the wisdom of running a service popular enough
to require use limits via a dialup, but it certainly will happen.

> > 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.
> 
> Developer's choice.
> 
> I chose to return a "too busy" message because I felt that the user on the
> other end is entitled to a prompt, rational explanation as to why the
> request wasn't satisfied. Creating a secondary queue (a queue of incoming
> connections waiting to complete) is prolonging the inevitable. That queue
> can run out (most sockets packages can queue 4-5, I believe). 

Making explicit "too busy" messages has potential problems too, of course,
since those messages themselves take some load (probably an appreciable
fraction of the load of an ordinary request, since most documents are
generally fairly short and the request with all its accept headers can get
rather lengthy.)

It is, of course, inevitable that users will start clicking on "reload"
over and over to get past the "too busy" message given the high turnover of 
sessionless HTTP, this is actually a fairly reasonable thing to do.
Eventually someone will design a client that does it automatically.
Then what?

> If the user gets back some obscure "connection refused" message, he's gonna
> think maybe the server's broken, the network is broken, his client is
> broken, the URL is broken, he is broken, who knows?  I hate that. Kinda
> like "SYNTAX ERROR".

Yup.  But I'd rather see the data a little late than a note to that effect.