Toby wrote:
> Hmm, yes. ZRendezvous doesnt have any choice but to queue up 
> the request. 
> Handling the request at that point could cause problems 
> because the support 
> for pipelined http requests might cause another recursive call to 
> ZRendezvous.handle, and deadlock. You need to handle it earlier.
> Maybe tweak the readable() method of zhttp_server and 
> zhttp_channel in
>, to stop bytes coming in over the socket if the 
> queue is too large.
> ?

Hm.  And making this limit (and the listen backlog parameter) available
as configuration options. :)

Not letting bytes through is not enough, though.  I think a 503 error
should be returned as quickly as possible back to the client.

> > I wonder if Zope also processes requests that have been closed from 
> > the client end?
> It will
> >  I know Zope will continue processing a request even if it 
> > times out 
> > at least (so you can do long-running requests, like 
> > packing, through 
> > the web).  Many (all?) of these 300 requests would have 
> > been closed by
> > the time Zope got to process them, and so Zope shouldn't 
> > bother with them.
> That doesnt need fixing. It wouldnt be a problem if the queue 
> was kept small.

Well, I think it would help in many cases.  Many people click on links
before the server has finished (or before it has even visibly started)
serving up pages.  Searching the web today I saw a commercial product (I
think it was a load balancer) promoting this as an important feature.

Any page for which the client has closed the connection before the
server has started serving up the page could be skipped.  If the server
has already started serving up the page, it could complete the


Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to