[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 [EMAIL PROTECTED] To: Chris Withers [EMAIL PROTECTED] References: [EMAIL PROTECTED] 001b01c24aea$6fa37060$6717a8c0@dorothy [EMAIL PROTECTED] 1030196732.1365.34.camel@james [EMAIL PROTECTED] 1030216329.1327.114.camel@james [EMAIL PROTECTED] 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 - [EMAIL PROTECTED] 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 ) ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Fwd: Re: [Zope-dev] Browser Stop Button and Zope REQUESTs]
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 [EMAIL PROTECTED] 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 ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Fwd: Re: [Zope-dev] Browser Stop Button and Zope REQUESTs]
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 [EMAIL PROTECTED] 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 ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Fwd: Re: [Zope-dev] Browser Stop Button and Zope REQUESTs]
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. ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
[Zope-dev] Browser Stop Button and Zope REQUESTs
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 - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] Browser Stop Button and Zope REQUESTs
Chris Withers wrote: I know I'm late in on this thread, but I thought I'd throw in my views. This is very nice, it seemed like nobody was interested in that. I'd like to see the REQUEST be flat plain aborted when someone hits the stop button or the connection dies. Yes, that would be the optimal solution. Unfortunately it seems to be (nearly) impossible to do. 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? The problem seems to be that when you started the sql query, there's not much zope could do, even if it knew that the stop button was pressed - if I understand Chris correctly, that. I'm all for isClientConnected, because it gives you at least the possiblity to find out about aborted connections. This could come in handy _before_ starting long sql-queries/other expensive tasks. But, like you, I think zope should be a little bit more clever out-of-the-box at it is now. 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. Hmm, can a pack always safely rolled back? As a parting example, what happens if I accidentally start a pack? How can I stop it? ;-) Hit the power button on the server ;-))). I did do some diggin about mod_perl and java meanwhile, maybe zope can learn something here. Mod_perl also seems _not_ to stop a long running script if this script doesn't try to write to the RESPONSE (or whatever they call it). The perl test script I posted does write output, and this causes it to stop. If I try a script with no output, it never gets stopped. Java servlets also seem only to get stopped automatically if they try to write into the RESPONSE stream of a closed connection. Buffering aside, if you try to output something in a servlet and the connection is closed, you get an exception. Im my uninformed opinion, Zope should do the same. Is this possible? cheers, oliver ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] Browser Stop Button and Zope REQUESTs
Oliver Bleutgen wrote: Mod_perl also seems _not_ to stop a long running script if this script doesn't try to write to the RESPONSE (or whatever they call it). The perl test script I posted does write output, and this causes it to stop. If I try a script with no output, it never gets stopped. Java servlets also seem only to get stopped automatically if they try to write into the RESPONSE stream of a closed connection. Buffering aside, if you try to output something in a servlet and the connection is closed, you get an exception. Im my uninformed opinion, Zope should do the same. Is this possible? Although Zope has a response stream method of sending information back to the client, most things in Zope don't use it. Instead, the response information is aggregated, converted into a string, and then sent back all at once at the sucessful completion of the transaction. These other systems you mention are using the availability of a response stream as a surrogate for RESPONSE.isClientConnected(). I'd rather have an explicit RESPONSE.isClientConnected(). Although, it would make sense to raise an exception if someone tried to write to the Zope response stream, in the rare cases when this does happen. -- Steve Alexander ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] Browser Stop Button and Zope REQUESTs
Steve Alexander wrote: Oliver Bleutgen wrote: Although Zope has a response stream method of sending information back to the client, most things in Zope don't use it. Instead, the response information is aggregated, converted into a string, and then sent back all at once at the sucessful completion of the transaction. Well, then it may be difficult to get zope to behave like the other systems, right? These other systems you mention are using the availability of a response stream as a surrogate for RESPONSE.isClientConnected(). I'd rather have an explicit RESPONSE.isClientConnected(). This is not correct. The systems I mentioned do also have the possibility to check if the client is still connected, it's just that they additionally prevent writing to a response which will never get delivered. This is quite reasonable IMO. Although, it would make sense to raise an exception if someone tried to write to the Zope response stream, in the rare cases when this does happen. I know we are talking about extreme cases here. But the behavior of java and mod_perl may prevent the whole system from falling over on a loaded server. This is made worse by the relative small number of threads which are running on a stock zope. cheers, oliver ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] Browser Stop Button and Zope REQUESTs
FWIW, I just checked in a signal handler to the trunk that makes it possible on UNIX to do kill -USR1 `cat var/Z2.pid` and pack the database to 0 days, so all this business about packing TTW and whether you need to let the browser wait or not is for naught. ;-) On Wed, 2002-08-28 at 07: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 - [EMAIL PROTECTED] 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 ) ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
