[Zope-dev] browser closing connection

[Leonardo Rochael Almeida]

Hi, all

On Fri, 2001-12-07 at 11:19, Matthew T. Kromer wrote:

> >Also, for the record we usually get a bunch of these quite often:
> >
> >2001-11-04T09:04:33 ERROR(200) ZServer uncaptured
> >  python exception, closing channel <zhttp_channel connected
> >  XXX.XXX.XXX.XXX:2181 at fb4edc channel#: 2286 requests:4>
> >  (socket.error:(32, 'Broken pipe')
> >
> >[/usr/local/zope/dist/Zope-2.4.1/ZServer/medusa/asynchat.py|initiate_send|21
> >4] [/usr/local/zope/dist/Zope-2.4.1/ZServer/medusa/http_server.py|send|414]
> >[/usr/local/zope/sw/Python2.1.1/lib/python2.1/asyncore.py|send|330])
> >
> >
> >We were seeing the same error (asyncore.py|send|330, etc) on solaris.
> >
> >Any thoughts
> >
> 
> Well, that means "the browser user clicked 'stop'"  -- Medusa is just 
> telling you the channel went away on it.  Thats normal when the browser 
> chops the tcp connection.
> 

As Dario said, it's a relief to know that. but if it's an expected
scenario, shouldn't zope put a more graceful message on the log?

Also, I write several long running process pages, and I make use of
RESPONSE.write() for that so as not to upset the browser or the user (or
zope memory consumption, when I have a lot of data to show during the
time). And I'd like a way to know when the user closes the channel, so
that I can stop the processing.

Case in point, I work with Lalo in the ZUnit framework (it's a little
dormant now (actually you could say it's in comatose), but I intend to
reawaken it shortly). And I'd like to stop the processing of test cases
when the user press the stop button in his browser.

In other cases, (like when I'm manually recataloging a huge bunch of
objects for which using the 'ZCatalog Find' would just time-out) I just
want to ignore if the user closed his browser after making the request.

Speaking of streaming pages, I'd really like if I didn't need to use an
external method just to print a damn traceback. That facility, if used
inside the standard_error_page would obviate the need to always print a
traceback in the error page, but I guess this has already been discussed
before...

Cheers, Leo

-- 
Ideas don't stay in some minds very long because they don't like
solitary confinement.