Zope should have something like ASP's Response.IsClientConnected method, which would allow app code to manually abort the processing of a request in strategic places if the connection has already been closed. I mentioned this a while back, but never did do anything about it. On Wed, 2004-02-11 at 20:05, Bjorn Stabell wrote:
Bjorn wrote:
I wonder if Zope also processes requests that have been closed from the client end? 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.
Casey wrote:
Why would they be closed by the client?
Two scenarios:
1) The user gets tired of waiting for the page to come up after a few seconds and stopes or reloads it. This is very common if the response time is above a few seconds.
2) After clicking on a link the user discovers another, better link, and quickly clicks on that one as well. This is quite common for me, at least :)
When Zope gets very loaded, response times suffer and these things happen more often; in our case with 300 requests in the pending queue, nobody would bother waiting 10 minutes for their page to come up (they'd stop the page loading and go somewhere else), so all the requests (most likely) would be needless; Zope is in fact just processing dead requests.
Bye,