[Zope-dev] Handling of ECONNRESET socket error in asyncore.py

[Chris McDonough]

On Fri, 2002-08-23 at 17:59, Oliver Bleutgen wrote:
> Hmm, how should the browser come back? Where to? The TCP-connection is 
> closed. You have no way to get data back to the browser. Press the stop 
> button, tear the network out of the wall, the thread won't stop.

When you come back, you'd come back to another thread, but presumably
the other thread would either still be running or will have finished.

> Maybe you say that someone may want to start a long running job per 
> browser request, like report creation or mass mailing, but who on his 
> right mind would implement something that way?

Not sure if I'm in my right mind, but I cause long-running requests a
fair amount.  Packing a large databases, reindexing large catalogs,
creating PDFs... sometimes you can't avoid it.

> Imagine you have one slow/hanging page, maybe representing data from an 
> overloaded sql-database connected to zope. As it is now, sooner or later 
> all of zope's worker threads will end up hanging there, making the site 
> inaccessible, while the users who requested the offending pages have 
> shut down their clients long ago. Yes, I know, there may some other 
> timeouts kick in, but the principle still stands.

Right, there is a real issue here.

Did you read my suggestion for a new Zope feature e.g.
REQUEST.RESPONSE.isClientConnected?  It would let the programmer
explicitly decide when to stop processing based on the connection status
of the browser.  Adding this feature would make it possible for a
programmer to influence execution in arbitrary ways based on client TCP
connection status without impacting backwards compatibility.  For
example with your "slow/hanging page", maybe each iteration through a
loop that obtains data from the database would check the flag and stop
processing if the user has gone away, e.g.:

l = []
while database.next():
    # pretend "slow" inner loop
    l.append(database.getData())
    if not context.REQUEST.RESPONSE.isClientConnected():
        return l
return l
    
> Apache + mod_perl don't do that, btw, and I bet a lot of other servers 
> don't do also.

Are you sure?  As far as I know, under mod_perl, the 'page' continues to
be executed after the user presses the stop button.

The "mod_perl developer's cookbook" also recommends something like I'm
suggesting with 'isClientConnected': 
http://webreference.com/programming/perl/cookbook/chap4/5.html as well.

- C