From: Dietmar S. <di...@sc...> - 2003-08-29 20:02:47
|
Hi! I have some long running applets. If the user cancels the transfer I would like to stop further execution. I can see StreamOut Error: (10053, 'Software caused connection abort") in the console window. Can the applet get this information to cancel execution? Regards, Dietmar |
From: Matt F. <ma...@da...> - 2003-09-02 19:29:17
|
Dietmar Schwertberger wrote: >I can see > StreamOut Error: (10053, 'Software caused connection abort") >in the console window. > > I don't have a solution for you, but I can say that we've seen this as well; we saw it a long time ago, when accidentally serving large binary files with a servlet. We worked around it by piping those files through apache. As far as I know, this problem hasn't been fixed. |
From: <web...@ka...> - 2003-09-02 20:00:26
|
--> Tuesday, September 2, 2003, 2:33:30 PM, ma...@da... wrote: > Dietmar Schwertberger wrote: >>I can see >> StreamOut Error: (10053, 'Software caused connection abort") >>in the console window. >> >> > I don't have a solution for you, but I can say that we've seen this as > well; we saw it a long time ago, when accidentally serving large binary > files with a servlet. We worked around it by piping those files through > apache. > As far as I know, this problem hasn't been fixed. I almost replied to Dietmar earlier, but figured I could not be helpful. Matt, your problem sounds like a simple timeout limitation. Which means it should be possible to fix via a configuration value or similar. I assume Webware allows this in a global configuration, but it is also going to be useful to allow a very granular configuration of this to set in rare pages via the API. If these things are not possible, perhaps they should be. A third thing to consider is allowing configuration of the timeout on the URL. For example : mypage.psp?_WWTimeout=120000. However, this is the THIRD thing to consider, so don't get hungup on it. I understand people might not like it. Then again, I was once flamed by Webware advocates for explaining PHP's helpful handling of form variables, such as naming them with [] postfixed to put multiple into an array. Next thing you know I am checking out WebWare and see very nearly the same abstract concept in form variable actions prefixed with _. So you never know, and that is why I mentioned the third. -Kai |
From: Ian B. <ia...@co...> - 2003-09-02 20:25:04
|
On Tuesday, September 2, 2003, at 03:00 PM, web...@ka... wrote: > --> Tuesday, September 2, 2003, 2:33:30 PM, ma...@da... wrote: > >> Dietmar Schwertberger wrote: > >>> I can see >>> StreamOut Error: (10053, 'Software caused connection abort") >>> in the console window. >>> >>> >> I don't have a solution for you, but I can say that we've seen this as >> well; we saw it a long time ago, when accidentally serving large >> binary >> files with a servlet. We worked around it by piping those files >> through >> apache. > >> As far as I know, this problem hasn't been fixed. > > I almost replied to Dietmar earlier, but figured I could not be > helpful. > > Matt, your problem sounds like a simple timeout limitation. Which > means it > should be possible to fix via a configuration value or similar. > > I assume Webware allows this in a global configuration, but it is also > going > to be useful to allow a very granular configuration of this to set in > rare > pages via the API. If these things are not possible, perhaps they > should be. Webware doesn't time anything out (maybe to its detriment -- though I don't know if there's any good way to do a timeout in a threaded environment anyway). I don't know if there's any way to put a timeout on a particular socket. If there is, Webware doesn't do it (or leaves it at the default timeout). In this case Apache is probably timing out. > A third thing to consider is allowing configuration of the timeout on > the URL. > For example : mypage.psp?_WWTimeout=120000. However, this is the THIRD > thing > to consider, so don't get hungup on it. I understand people might not > like it. > > Then again, I was once flamed by Webware advocates for explaining PHP's > helpful handling of form variables, such as naming them with [] > postfixed to > put multiple into an array. Next thing you know I am checking out > WebWare > and see very nearly the same abstract concept in form variable actions > prefixed with _. So you never know, and that is why I mentioned the > third. Actions are done with the _action_X form variable, but confirmed with the servlet's actions() method. So the client never invokes something that wasn't explicitly permitted by the developer. In this case the configuration (if it existed) would best be put directly in the servlet, as per-request configuration (as opposed to per-servlet) seems unlikely. Ian |
From: <web...@ka...> - 2003-09-02 20:41:47
|
--> Tuesday, September 2, 2003, 3:24:54 PM, ia...@co... wrote: > Webware doesn't time anything out (maybe to its detriment -- though I > don't know if there's any good way to do a timeout in a threaded > environment anyway). I don't know if there's any way to put a timeout > on a particular socket. If there is, Webware doesn't do it (or leaves > it at the default timeout). I would think there are. Perhaps they are not available to Python. Perhaps this explains my experience with Python TCP/IP in Windows. I tried Python for TCP/IP development in Windows one time and experienced hugely obscure bugs in an application which transferred around 50 thousand data files daily. The errors *were* rare and messages hilariously useless. After 4 fulls days of trying to find the problem, I ported my code to Delphi rather easily and the errors were gone completely. I never got to use Python at that employer again and haven't trusted it completely for TCP/IP since. > In this case Apache is probably timing out. >> Then again, I was once flamed by Webware advocates for explaining PHP's >> helpful handling of form variables, such as naming them with [] postfixed >> to put multiple into an array. Next thing you know I am checking out >> WebWare and see very nearly the same abstract concept in form variable >> actions prefixed with _. So you never know, and that is why I mentioned >> the third. > Actions are done with the _action_X form variable, but confirmed with > the servlet's actions() method. So the client never invokes something > that wasn't explicitly permitted by the developer. In this case the > configuration (if it existed) would best be put directly in the > servlet, as per-request configuration (as opposed to per-servlet) seems > unlikely. Yes I know actions must be defined in the servlet quite obviously for security measures. Postfixing with [] in PHP doesn't come close to that type of security vulnerability. I was flamed because the convention existed, not because of any possible security vulnerability, then come to find similar conventions in Webware (even less elegant imho). That's all I was saying. -Kai |
From: Nick M. <ni...@go...> - 2003-09-03 08:04:47
|
Ian Bicking wrote: > Webware doesn't time anything out (maybe to its detriment -- though I > don't know if there's any good way to do a timeout in a threaded > environment anyway). I don't know if there's any way to put a timeout > on a particular socket. If there is, Webware doesn't do it (or leaves > it at the default timeout). From http://www.python.org/2.3/highlights.html: socket - sockets now support an optional timeout on all operations. Code by Michael Gilfix and Bernard Yue, based on Tim O'Malley's timeoutsocket.py. Nick |
From: Matt F. <ma...@da...> - 2003-09-02 20:06:15
|
web...@ka... wrote: >Matt, your problem sounds like a simple timeout limitation. Which means it >should be possible to fix via a configuration value or similar. > > It seems like it should be that simple, but I'm not sure that the appserver has any way of knowing that the client has "stopped". It's still probably trying to squirt the response back at apache, and the packets don't go anywhere. It seems to want to exhaust every packet, which for a 100M movie file is a lot. >I assume Webware allows this in a global configuration, but it is also going >to be useful to allow a very granular configuration of this to set in rare >pages via the API. If these things are not possible, perhaps they should be. > This is probably more about apache (or whatever web server) that Ww itself. I found a message from Geoff from a couple of years ago that references this problem: ---------------------- Clark, I am unable to reproduce the "Webware death" problem at home on my Linux Mandrake 8.1 box. Whenever I cancel a long, large servlet prematurely, the exception handler get triggered due to the broken pipe, as you would expect. But nothing crashes. The StreamOut Error: (10053, 'Software caused connection abort') message you see on Windows NT is also normal. In fact, the exception handler should be modified so that it simply ignores that message -- that's just what you get on Windows instead of EPIPE when the connection is canceled. So I'm now 98% convinced that this is an OS bug, not a Webware bug or Python bug (I'm also using Python 2.1.1). I would suggest trying a newer version of Linux. |
From: <web...@ka...> - 2003-09-02 20:30:05
|
--> Tuesday, September 2, 2003, 3:10:47 PM, ma...@da... wrote: > web...@ka... wrote: >>Matt, your problem sounds like a simple timeout limitation. Which means it >>should be possible to fix via a configuration value or similar. >> >> > It seems like it should be that simple, but I'm not sure that the > appserver has any way of knowing that the client has "stopped". It's > still probably trying to squirt the response back at apache, and the > packets don't go anywhere. It seems to want to exhaust every packet, > which for a 100M movie file is a lot. Exactly. This is fairly common in web application frameworks and servers. I don't know of any that handle this well. I have always believed it is a paradox of HTTP servers, but have never cared to elaborate on that belief. I have experienced it everywhere and would look into the Webware timing out code or configuration option...? I don't know Webware very well, but I have used many web servers and application frameworks in Windows and they all have these sorts of problems. If you made it work with Apache, Webware is a good place to look for a fix... *shrug* >>I assume Webware allows this in a global configuration, but it is also going >>to be useful to allow a very granular configuration of this to set in rare >>pages via the API. If these things are not possible, perhaps they should be. >> > This is probably more about apache (or whatever web server) that Ww itself. Yes, but it would also need to be about Webware. Since you mentioned you fixed it by going through Apache only, I guessed Webware threading/timeout mechanisms were occurring before Apache's. I know this dilemma exists most everywhere, I just guessed Webware was the location in need of configuration and/or changing based on your piping fix. > I found a message from Geoff from a couple of years ago that references > this problem: Hmm, that's curious and possible I guess, but I can't imagine it being something like forking where it is simply not possible in Windows. I feel this way because I can't imagine there being any similar/converse magic in the MS networking code to cause this. I think we'd of heard about it as we do about process forking. -Kai |
From: Dietmar S. <mai...@sc...> - 2003-09-02 21:32:42
|
In <URL:news:local.News> on Tue 02 Sep, Matt Feifarek wrote: > web...@ka... wrote: > I found a message from Geoff from a couple of years ago that references > this problem: > > ---------------------- > > Clark, > > I am unable to reproduce the "Webware death" problem at home on my Linux > Mandrake 8.1 box. Whenever I cancel a long, large servlet prematurely, > the > exception handler get triggered due to the broken pipe, as you would > expect. > But nothing crashes. > > The StreamOut Error: (10053, 'Software caused connection abort') message > you > see on Windows NT is also normal. In fact, the exception handler should > be > modified so that it simply ignores that message -- that's just what you > get > on Windows instead of EPIPE when the connection is canceled. > > So I'm now 98% convinced that this is an OS bug, not a Webware bug or > Python > bug (I'm also using Python 2.1.1). I would suggest trying a newer version > of > Linux. Can anybody tell what happens on Linux on cancellation of transfers? Does the servlet see an exception? If yes, is this at defined points? Regards, Dietmar |
From: Ian B. <ia...@co...> - 2003-09-02 20:30:02
|
On Friday, August 29, 2003, at 02:45 PM, Dietmar Schwertberger wrote: > I have some long running applets. If the user cancels the transfer I > would > like to stop further execution. > > I can see > StreamOut Error: (10053, 'Software caused connection abort") > in the console window. > > Can the applet get this information to cancel execution? (I assume you mean servlets) sleep() should be called regardless of any exceptions. So this should work (untested): def writeHTML(self): self.finishedLongThing = 0 while 1: output = self.doSomethingLong() if not output: break self.write(output) self.finishedLongThing = 1 def sleep(self, trans): if not self.finishedLongThing: self.killSomethingLong() If the particular exception you're getting causes sleep() not to be called, then that's a bug. Ian |
From: <web...@ka...> - 2003-09-02 20:46:57
|
--> Tuesday, September 2, 2003, 3:29:55 PM, ia...@co... wrote: > (I assume you mean servlets) > sleep() should be called regardless of any exceptions. So this should > work (untested): This reminded me of a question I've had for a while. Can I make my exceptions printout in the current/existing HTML results of my PSP/Servlet instead of overwriting the entire page? Is this impossible? I can think of a couple reasons it may not be... :( -Kai |
From: Dietmar S. <mai...@sc...> - 2003-09-02 21:32:38
|
In <URL:news:local.News> on Tue 02 Sep, Ian Bicking wrote: > On Friday, August 29, 2003, at 02:45 PM, Dietmar Schwertberger wrote: > > I have some long running applets. If the user cancels the transfer I > > would > > like to stop further execution. > > > > I can see > > StreamOut Error: (10053, 'Software caused connection abort") > > in the console window. > > > > Can the applet get this information to cancel execution? > > (I assume you mean servlets) > > sleep() should be called regardless of any exceptions. So this should > work (untested): > > def writeHTML(self): > self.finishedLongThing = 0 > while 1: > output = self.doSomethingLong() > if not output: break > self.write(output) > self.finishedLongThing = 1 > > def sleep(self, trans): > if not self.finishedLongThing: > self.killSomethingLong() > > If the particular exception you're getting causes sleep() not to be > called, then that's a bug. I thought that 'StreamOut Error' is a message from mod_python which is just printed to stderr. But then there's the post from Matt/Geoff suggesting this is an OS problem. The servlet doesn't notice any exception or error. It continues serving until it has finishedLongThing even if the user's browser stopped receiving the output long before ... sleep() will be called afterwards, but then the (useless) work already has been done. This is especially a problem because a user may do several cancels and reloads ... Regards, Dietmar |
From: <web...@ka...> - 2003-09-02 23:23:34
|
--> Tuesday, September 2, 2003, 4:31:26 PM, mai...@sc... wrote: > In <URL:news:local.News> on Tue 02 Sep, Ian Bicking wrote: > I thought that 'StreamOut Error' is a message from mod_python which is just > printed to stderr. But then there's the post from Matt/Geoff suggesting this > is an OS problem. If Webware doesn't have a timeout as Ian mentioned, then the 'Software cause connection abort' message being seen seems to make sense when Apache reaches its Timeout limit and kills the connection, at which point Webware is probably confused and Python is reporting the error. Has either of you just tried setting the Apache Timeout directive very high? -Kai |
From: Dietmar S. <mai...@sc...> - 2003-09-03 20:04:29
|
In <URL:news:local.News> on Wed 03 Sep, web...@ka... wrote: > > --> Tuesday, September 2, 2003, 4:31:26 PM, mai...@sc... wrote: > > > In <URL:news:local.News> on Tue 02 Sep, Ian Bicking wrote: > > > I thought that 'StreamOut Error' is a message from mod_python which is just > > printed to stderr. But then there's the post from Matt/Geoff suggesting this > > is an OS problem. > > If Webware doesn't have a timeout as Ian mentioned, then the 'Software cause > connection abort' message being seen seems to make sense when Apache reaches > its Timeout limit and kills the connection, at which point Webware is > probably confused and Python is reporting the error. > > Has either of you just tried setting the Apache Timeout directive very high? The problem ist surely not timeout related as it immediately happens after cancelling the transfer. >From the sources of NewThreadedAppServer.py: from WebKit.ASStreamOut import ASStreamOut class TASASStreamOut(ASStreamOut): def __init__(self, sock): ASStreamOut.__init__(self) self._socket = sock def flush(self): debug=0 result = ASStreamOut.flush(self) if result: ##a true return value means we can send reslen = len(self._buffer) sent = 0 while sent < reslen: try: sent = sent + self._socket.send(self._buffer[sent:sent+8192]) except socket.error, e: if e[0]==errno.EPIPE: #broken pipe pass else: print "StreamOut Error: ", e break self.pop(sent) This just ignores the socket.error. I think it would be a good idea to give the application a possibility to find out about the error state, e.g. through setting an error flag or a return value. I'm not sure about the errno.EPIPE, but if the pipe is broken, what sense does it make to re-try sending more data? Regards, Dietmar |
From: Stuart D. <st...@as...> - 2003-09-03 20:23:58
|
I encountered this, and have a fix for it which I had thought I had put into a bug report. The essence of the solution I chose was to raise an AbortResponse exception. I derived AbortResponse from EndResponse and then had to put a couple of other catches in Application.py as I recall in case the servlet did not catch it. Are you using 0.8.1 or the CVS version? I have not yet applied my fix to the CVS trunk version of the code yet, but I could probably do that in the near future if you are interested. I have been meaning to upgrade to the latest changes in CVS anyway. -Stuart - Dietmar Schwertberger wrote: >In <URL:news:local.News> on Wed 03 Sep, web...@ka... wrote: > > >>--> Tuesday, September 2, 2003, 4:31:26 PM, mai...@sc... wrote: >> >> >> >>>In <URL:news:local.News> on Tue 02 Sep, Ian Bicking wrote: >>> >>> >>>I thought that 'StreamOut Error' is a message from mod_python which is just >>>printed to stderr. But then there's the post from Matt/Geoff suggesting this >>>is an OS problem. >>> >>> >>If Webware doesn't have a timeout as Ian mentioned, then the 'Software cause >>connection abort' message being seen seems to make sense when Apache reaches >>its Timeout limit and kills the connection, at which point Webware is >>probably confused and Python is reporting the error. >> >>Has either of you just tried setting the Apache Timeout directive very high? >> >> > >The problem ist surely not timeout related as it immediately happens >after cancelling the transfer. > > > > >>>From the sources of NewThreadedAppServer.py: >> >> > > >from WebKit.ASStreamOut import ASStreamOut >class TASASStreamOut(ASStreamOut): > > def __init__(self, sock): > ASStreamOut.__init__(self) > self._socket = sock > > def flush(self): > debug=0 > result = ASStreamOut.flush(self) > if result: ##a true return value means we can send > reslen = len(self._buffer) > sent = 0 > while sent < reslen: > try: > sent = sent + self._socket.send(self._buffer[sent:sent+8192]) > except socket.error, e: > if e[0]==errno.EPIPE: #broken pipe > pass > else: > print "StreamOut Error: ", e > break > self.pop(sent) > > >This just ignores the socket.error. I think it would be a good idea to give >the application a possibility to find out about the error state, e.g. >through setting an error flag or a return value. > >I'm not sure about the errno.EPIPE, but if the pipe is broken, what sense >does it make to re-try sending more data? > > >Regards, > >Dietmar > > > > > > >------------------------------------------------------- >This sf.net email is sponsored by:ThinkGeek >Welcome to geek heaven. >http://thinkgeek.com/sf >_______________________________________________ >Webware-discuss mailing list >Web...@li... >https://lists.sourceforge.net/lists/listinfo/webware-discuss > > > > |
From: Dietmar S. <mai...@sc...> - 2003-09-04 17:30:59
|
In <URL:news:local.News> on Wed 03 Sep, Stuart Donaldson wrote: > I encountered this, and have a fix for it which I had thought I had put > into a bug report. > > The essence of the solution I chose was to raise an AbortResponse > exception. I derived AbortResponse from EndResponse and then had to put > a couple of other catches in Application.py as I recall in case the > servlet did not catch it. > > Are you using 0.8.1 or the CVS version? I have not yet applied my fix > to the CVS trunk version of the code yet, but I could probably do that > in the near future if you are interested. I have been meaning to > upgrade to the latest changes in CVS anyway. I'm still using 0.8.0 (but without "smart" cookies...), because the bug http://sourceforge.net/tracker/index.php?func=detail&aid=697350&group_id=4866&atid=104866 is still open in 0.8.1. (Yes I know, I should have submitted this as patch...) Where do you rise this exception? Just in flush() or also somewhere else? For me this would a solution, but it could break some applets for other people if they don't have a try/except or try/finally around their code ... The change of flush() to return a value<>None would be 100% backward compatible. Regards, Dietmar |