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?


Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to