[Fwd: Re: [Zope-dev] Browser Stop Button and Zope REQUESTs]
I think Tim meant this to go to the list ;-) Chris -------- Original Message -------- Subject: Re: [Zope-dev] Browser Stop Button and Zope REQUESTs Date: 29 Aug 2002 14:36:30 +0800 From: Tim Hoffman <timhoffman@cams.wa.gov.au> To: Chris Withers <chrisw@nipltd.com> References: <3D66A3E5.5050302@gmx.net> <001b01c24aea$6fa37060$6717a8c0@dorothy> <3D66B042.1090900@gmx.net> <1030196732.1365.34.camel@james> <3D67C9D7.4000501@gmx.net> <1030216329.1327.114.camel@james> <3D6CB8AD.40206@nipltd.com> Hi Just my 2c worth, I wouldn't want this to be a blanket approach if it where ever implemented. If my ZODB is so big that it takes half an hour to rebuild, I would hate it to be aborted just because the browser lost it's connection (ie IE crashed ;-) or running a big import. I don't need the browser to hang around for the end result, I just want it to complete at some point. (ie kicking off long running processes through xml-rpc, I don't want to keep the connection open for the duration.) Either you can programatically look at the state of the connection (within the process and chose to kill it) or there was a console tool so that you could see long running threads and kill them. Rgds Tim On Wed, 2002-08-28 at 19:49, Chris Withers wrote:
I know I'm late in on this thread, but I thought I'd throw in my views.
I'd like to see the REQUEST be flat plain aborted when someone hits the stop button or the connection dies.
I don't is the is context.REQUEST.RESPONSE.isClientConnected() really working. How would I plug this in an expensive SQL SELECT/JOIN? Why do we need this extra programming overhead?
As for the long running administrative tasks, I actually see the ability to bugger off and leave them running as an extremely bad thing. Say I hit 'pack' on a big fat ZODB. I then go somewhere else. How do I now tell when its done? The only was would be to go and look at 'top' and guess which python thread is doing the pack and wait till its CPU usage drops to zero. That's pretty ropey ;-) For the same reason, I hate ZEO's pack's possibility of returning before a pack is finished.
If you do a pack, I really think you should wait for the browser to return. If the browser times out, then use something like wget. If I hit 'stop', the pack should abort.
As a parting example, what happens if I accidentally start a pack? How can I stop it? ;-)
cheers,
Chris
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
On Thu, 29 Aug 2002 11:41:44 +0100, Chris Withers spoke forth:
-------- Original Message -------- Subject: Re: [Zope-dev] Browser Stop Button and Zope REQUESTs Date: 29 Aug 2002 14:36:30 +0800 From: Tim Hoffman <timhoffman@cams.wa.gov.au>
If my ZODB is so big that it takes half an hour to rebuild, I would hate it to be aborted just because the browser lost it's connection (ie IE crashed ;-)
or running a big import. I don't need the browser to hang around for the end result, I just want it to complete at some point. (ie kicking off long running processes through xml-rpc, I don't want to keep the connection open for the duration.)
This brings up a question I've always had, is it possible to "fork" a request into the background. Your example being an import, is it possible to set up the import script to do the following: * User requests that some import file be imported * Zope makes sure it's a valid import file (extension or whatever it does, basically that it exists) * Zope forks the import off into the background * Zope responds to the request saying "The import is in progress, blahdy blahdy blah." Meanwhile, the user gets instant feedback that his import is going, and doesn't have to wait for the browser to say anything, or time out, whichever comes first. I think this would be very useful if one were writing something like an order processing system, where you wanted to build the order processing into Zope. Someone adds junk to their "shopping cart", clicks the "send me my junk" button, and gets instant feedback telling him that the order is being processed. I can think of lots of uses for that kind of thing. Oh, and back on the original topic, does anyone know for sure if the browsers actually send something to the server when "stop" is pressed?
Either you can programatically look at the state of the connection (within the process and chose to kill it) or there was a console tool so that you could see long running threads and kill them.
A console tool for managing threads would be great. Being able to kill off a request, like one of our users hitting the undo or history tab, would be nice, until we get a patch going for that. Some things just take way too long. -Chris
Christopher N. Deckard wrote:
Oh, and back on the original topic, does anyone know for sure if the browsers actually send something to the server when "stop" is pressed?
Yes, it sends a "RST" packet. It ends the tcp-connection. That's why I think throwing an exception when something tries to output data to be served to such a connection is the right thing to do (while it may be not so easy to implement with zope, I don't know). Since the connection is gone, there's no point in accumulating data to be sent back. Tim Hoffman <timhoffman@cams.wa.gov.au> wrote:
Hi
Just my 2c worth,
I wouldn't want this to be a blanket approach if it where ever implemented.
If my ZODB is so big that it takes half an hour to rebuild, I would hate it to be aborted just because the browser lost it's connection (ie IE crashed ;-)
or running a big import. I don't need the browser to hang around for the end result, I just want it to complete at some point. (ie kicking off long running processes through xml-rpc, I don't want to keep the connection open for the duration.)
I don't know why these examples should be an argument against implementing a saner (just IMO!) policy into zope regarding connection resets. If something like I described would be implemented into zope, it surely should be possible to start an extra thread for doing the stuff you give as an example, or - less desireable IMO - to ignore the connection reset. If this were implemented with an exeption, you just had to catch it and you're done. cheers, oliver
On Thursday 29 Aug 2002 2:21 pm, Oliver Bleutgen wrote:
If something like I described would be implemented into zope, it surely should be possible to start an extra thread for doing the stuff you give as an example
The issue is that zope *already* runs *every* request in a seperate thread from the one that handles the connections, and has done since version 2.0. In most almost every case these worker threads will have finished their per-request work and all response data will have been calculated before the user has a chance to press the stop button.
participants (4)
-
Chris Withers -
Christopher N. Deckard -
Oliver Bleutgen -
Toby Dickenson