From: Geoffrey T. <gta...@na...> - 2002-11-01 19:39:59
|
I think that a broken pipe during TASASStreamOut.flush() should cause an exception to be raised, similar to the EndResponse exception in Application.py, that would just gracefully stop further processing. This would be a change from the current behavior, so it might break existing applications. Does anyone think that would be a big problem? Perhaps this new behavior should only be enabled if you call response.flush(endResponseOnBrokenPipe=1) (or just response.flush(1) for short). - Geoff > -----Original Message----- > From: Stuart Donaldson [mailto:st...@al...] > Sent: Friday, November 01, 2002 1:23 PM > To: Stuart Donaldson; Webware Discussion (E-mail) > Subject: RE: [Webware-discuss] Server Push detecting when the > client has > g one away. > > > Ok, managed to get somewhere on my own here. Apparently in > TASASStreamOut.flush() there is a Broken Pipe error being caught and > ignored. Any reason why this is silently ignored in flush, > rather than > being passed up to the caller, or at least being made available to the > caller? > > Seems like the the error should be thrown up further rather than just > ignored. Or at the very least, an error status should be > easily readable or > returned. > > Any ideas on this? > > -Stuart- > > > -----Original Message----- > > From: Stuart Donaldson > > Sent: Friday, November 01, 2002 10:03 AM > > To: Webware Discussion (E-mail) > > Subject: [Webware-discuss] Server Push detecting when the client has > > gone away. > > > > > > I tried the PushServlet, and am having problems when the > > client goes away. > > > > Basically the client web browser can break the connection by > > going on to > > another URL, or even just closing down. The PushServlet > > doesn't get any > > notification of this effect, and just keeps happily running until > > completion. > > > > Any ideas on where to look for a solution to this? I am > > using mod_webkit, > > is the status that the connection is closed even passed > > through from Apache > > into Webware? > > > > Stuart Donaldson > > Alerton Technologies Inc. > > > > > > > > ------------------------------------------------------- > > This sf.net email is sponsored by: See the NEW Palm > > Tungsten T handheld. Power & Color in a compact size! > > http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en > > _______________________________________________ > > Webware-discuss mailing list > > Web...@li... > > https://lists.sourceforge.net/lists/listinfo/webware-discuss > > > > > ------------------------------------------------------- > This sf.net email is sponsored by: See the NEW Palm > Tungsten T handheld. Power & Color in a compact size! > http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en > _______________________________________________ > Webware-discuss mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/webware-discuss > |
From: Stuart D. <st...@al...> - 2002-11-02 00:30:44
|
I suspect the reason the Pipe is caught in TASASStreamOut.flush() has to do with not wanting to generate Error files just because a browser went away. It unfortunately breaks by not detecting the case of a PushServlet running for a long time after the browser has closed down. Another option might be that response.flush() could return a success/failure result. This might be considered more consistent with the call to ASSreamOut.flush(). Although the meaning of the return value there is I either HAVE or DONOT HAVE data to flush. I am not really wild about changing the definition of return values in overloaded functions. ASStream.flush() might better be implemented as a different function, since its return value at present has no meaning to a caller of an instanciated object. Although if the definition of the return value of flush is interpreted as "There is still more data to flush," that could be used by a caller of response.flush() to say that something more needs to be done, such as checking an as yet to be implemented status. Anyway, a response.status() or response.error() method could be added that would return an instance of an exception if one had occurred. This could be set by the flush call when the exception occurs. -Stuart- > -----Original Message----- > From: Geoffrey Talvola [mailto:gta...@na...] > Sent: Friday, November 01, 2002 11:40 AM > To: Stuart Donaldson; Webware Discussion (E-mail) > Subject: RE: [Webware-discuss] Server Push detecting when the > client has > g one away. > > > I think that a broken pipe during TASASStreamOut.flush() > should cause an > exception to be raised, similar to the EndResponse exception in > Application.py, that would just gracefully stop further processing. > > This would be a change from the current behavior, so it might > break existing > applications. Does anyone think that would be a big problem? > Perhaps this > new behavior should only be enabled if you call > response.flush(endResponseOnBrokenPipe=1) (or just > response.flush(1) for > short). > > - Geoff > > > -----Original Message----- > > From: Stuart Donaldson [mailto:st...@al...] > > Sent: Friday, November 01, 2002 1:23 PM > > To: Stuart Donaldson; Webware Discussion (E-mail) > > Subject: RE: [Webware-discuss] Server Push detecting when the > > client has > > g one away. > > > > > > Ok, managed to get somewhere on my own here. Apparently in > > TASASStreamOut.flush() there is a Broken Pipe error being caught and > > ignored. Any reason why this is silently ignored in flush, > > rather than > > being passed up to the caller, or at least being made > available to the > > caller? > > > > Seems like the the error should be thrown up further rather > than just > > ignored. Or at the very least, an error status should be > > easily readable or > > returned. > > > > Any ideas on this? > > > > -Stuart- > > > > > -----Original Message----- > > > From: Stuart Donaldson > > > Sent: Friday, November 01, 2002 10:03 AM > > > To: Webware Discussion (E-mail) > > > Subject: [Webware-discuss] Server Push detecting when the > client has > > > gone away. > > > > > > > > > I tried the PushServlet, and am having problems when the > > > client goes away. > > > > > > Basically the client web browser can break the connection by > > > going on to > > > another URL, or even just closing down. The PushServlet > > > doesn't get any > > > notification of this effect, and just keeps happily running until > > > completion. > > > > > > Any ideas on where to look for a solution to this? I am > > > using mod_webkit, > > > is the status that the connection is closed even passed > > > through from Apache > > > into Webware? > > > > > > Stuart Donaldson > > > Alerton Technologies Inc. > > > > > > > > > > > > ------------------------------------------------------- > > > This sf.net email is sponsored by: See the NEW Palm > > > Tungsten T handheld. Power & Color in a compact size! > > > http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en > > > _______________________________________________ > > > Webware-discuss mailing list > > > Web...@li... > > > https://lists.sourceforge.net/lists/listinfo/webware-discuss > > > > > > > > > ------------------------------------------------------- > > This sf.net email is sponsored by: See the NEW Palm > > Tungsten T handheld. Power & Color in a compact size! > > http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en > > _______________________________________________ > > Webware-discuss mailing list > > Web...@li... > > https://lists.sourceforge.net/lists/listinfo/webware-discuss > > > |
From: Stuart D. <st...@al...> - 2002-12-13 14:46:33
|
I'm looking at this issue again, since I need to resolve it for a project. Current behavior of TASASStreamOut::flush() when the connection has been closed, is to silently ignore the errno.EPIPE condition when flushing data to the socket, and will at most print an error line on stdout for any other errors. Server push applications don't detect the error, and happily continue pushing data to nowhere. Do we really need to make raising an error when the stream can't be flushed a conditional operation? Under what conditions would you not want to do this? The only thing I can think of, is that existing applications might see the error and generate a log message of some sort? If we do need to make it conditional, I would prefer not to add an argument to flush(), but rather to make it a property on the output stream. Adding an argument to flush would add code on every flush() call, while checking a property on the stream need only be done when an error occurs. Another option might be to update the semantics of flush() to return a success/failure code. However that would change the return code meaning from ASStreamOut::flush() where it means we can send to TASASStreamOut::flush() where it mean we did not encounter any errors. Unless a normalized meaning of this can be established, it probably should not be done this way. If we raise an exception, Geoff suggested raising an exception similar to EndResponse. How about a subclass of EndResponse such that existing handlers for EndResponse would continue to catch the exception normally, but a caller could specifically catch the error. As I said, I need a fix. I have a solution which works for me, but would prefer to have a solution that would be acceptable in Webware. Can we just do the following: class EndResponseSocketError(EndResponse): pass ... class TASASStreamOut(ASStreamOut): ... def flush(self): ... try: sent = sent + self._socket.send(...) except socket.error, e: raise EndResponseSocketError(e) What do you think? -Stuart- > -----Original Message----- > From: Geoffrey Talvola [mailto:gta...@na...] > Sent: Friday, November 01, 2002 11:40 AM > To: Stuart Donaldson; Webware Discussion (E-mail) > Subject: RE: [Webware-discuss] Server Push detecting when the > client has > g one away. > > > I think that a broken pipe during TASASStreamOut.flush() > should cause an > exception to be raised, similar to the EndResponse exception in > Application.py, that would just gracefully stop further processing. > > This would be a change from the current behavior, so it might > break existing > applications. Does anyone think that would be a big problem? > Perhaps this > new behavior should only be enabled if you call > response.flush(endResponseOnBrokenPipe=1) (or just > response.flush(1) for > short). > > - Geoff > > > -----Original Message----- > > From: Stuart Donaldson [mailto:st...@al...] > > Sent: Friday, November 01, 2002 1:23 PM > > To: Stuart Donaldson; Webware Discussion (E-mail) > > Subject: RE: [Webware-discuss] Server Push detecting when the > > client has > > g one away. > > > > > > Ok, managed to get somewhere on my own here. Apparently in > > TASASStreamOut.flush() there is a Broken Pipe error being caught and > > ignored. Any reason why this is silently ignored in flush, > > rather than > > being passed up to the caller, or at least being made > available to the > > caller? > > > > Seems like the the error should be thrown up further rather > than just > > ignored. Or at the very least, an error status should be > > easily readable or > > returned. > > > > Any ideas on this? > > > > -Stuart- > > > > > -----Original Message----- > > > From: Stuart Donaldson > > > Sent: Friday, November 01, 2002 10:03 AM > > > To: Webware Discussion (E-mail) > > > Subject: [Webware-discuss] Server Push detecting when the > client has > > > gone away. > > > > > > > > > I tried the PushServlet, and am having problems when the > > > client goes away. > > > > > > Basically the client web browser can break the connection by > > > going on to > > > another URL, or even just closing down. The PushServlet > > > doesn't get any > > > notification of this effect, and just keeps happily running until > > > completion. > > > > > > Any ideas on where to look for a solution to this? I am > > > using mod_webkit, > > > is the status that the connection is closed even passed > > > through from Apache > > > into Webware? > > > > > > Stuart Donaldson > > > Alerton Technologies Inc. > > > > > > > > > > > > ------------------------------------------------------- > > > This sf.net email is sponsored by: See the NEW Palm > > > Tungsten T handheld. Power & Color in a compact size! > > > http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en > > > _______________________________________________ > > > Webware-discuss mailing list > > > Web...@li... > > > https://lists.sourceforge.net/lists/listinfo/webware-discuss > > > > > > > > > ------------------------------------------------------- > > This sf.net email is sponsored by: See the NEW Palm > > Tungsten T handheld. Power & Color in a compact size! > > http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en > > _______________________________________________ > > Webware-discuss mailing list > > Web...@li... > > https://lists.sourceforge.net/lists/listinfo/webware-discuss > > > |
From: Stuart D. <st...@al...> - 2002-12-13 14:58:41
|
Ok, I hate it when that happens... I just figured out something wrong with my suggestion not 2 minutes after I sent it off ;-( To prevent unnecessary logging of closed sockets, it looks like we would also need to catch the exception in Application::dispatchRequest(). Perhaps raising an exception such as AbortResponse which could be added, and when caught just cancels the transaction elements cleanly. The argument to the exception could continue to be the actual exception reason for aborting. -S- > -----Original Message----- > From: Stuart Donaldson > Sent: Friday, December 13, 2002 6:47 AM > To: 'Geoffrey Talvola'; Webware Discussion (E-mail) > Subject: RE: [Webware-discuss] Server Push detecting when the > client has > g one away. > > > I'm looking at this issue again, since I need to resolve it > for a project. > > Current behavior of TASASStreamOut::flush() when the > connection has been > closed, is to silently ignore the errno.EPIPE condition when > flushing data > to the socket, and will at most print an error line on stdout > for any other > errors. Server push applications don't detect the error, and happily > continue pushing data to nowhere. > > Do we really need to make raising an error when the stream > can't be flushed > a conditional operation? Under what conditions would you not > want to do > this? The only thing I can think of, is that existing > applications might > see the error and generate a log message of some sort? > > If we do need to make it conditional, I would prefer not to > add an argument > to flush(), but rather to make it a property on the output > stream. Adding > an argument to flush would add code on every flush() call, > while checking a > property on the stream need only be done when an error occurs. > > Another option might be to update the semantics of flush() to return a > success/failure code. However that would change the return > code meaning > from ASStreamOut::flush() where it means we can send to > TASASStreamOut::flush() where it mean we did not encounter any errors. > Unless a normalized meaning of this can be established, it > probably should > not be done this way. > > If we raise an exception, Geoff suggested raising an > exception similar to > EndResponse. How about a subclass of EndResponse such that existing > handlers for EndResponse would continue to catch the > exception normally, but > a caller could specifically catch the error. > > As I said, I need a fix. I have a solution which works for > me, but would > prefer to have a solution that would be acceptable in Webware. > > Can we just do the following: > > class EndResponseSocketError(EndResponse): > pass > ... > > class TASASStreamOut(ASStreamOut): > ... > def flush(self): > ... > try: > sent = sent + self._socket.send(...) > except socket.error, e: > raise EndResponseSocketError(e) > > What do you think? > > -Stuart- > > > -----Original Message----- > > From: Geoffrey Talvola [mailto:gta...@na...] > > Sent: Friday, November 01, 2002 11:40 AM > > To: Stuart Donaldson; Webware Discussion (E-mail) > > Subject: RE: [Webware-discuss] Server Push detecting when the > > client has > > g one away. > > > > > > I think that a broken pipe during TASASStreamOut.flush() > > should cause an > > exception to be raised, similar to the EndResponse exception in > > Application.py, that would just gracefully stop further processing. > > > > This would be a change from the current behavior, so it might > > break existing > > applications. Does anyone think that would be a big problem? > > Perhaps this > > new behavior should only be enabled if you call > > response.flush(endResponseOnBrokenPipe=1) (or just > > response.flush(1) for > > short). > > > > - Geoff > > > > > -----Original Message----- > > > From: Stuart Donaldson [mailto:st...@al...] > > > Sent: Friday, November 01, 2002 1:23 PM > > > To: Stuart Donaldson; Webware Discussion (E-mail) > > > Subject: RE: [Webware-discuss] Server Push detecting when the > > > client has > > > g one away. > > > > > > > > > Ok, managed to get somewhere on my own here. Apparently in > > > TASASStreamOut.flush() there is a Broken Pipe error being > caught and > > > ignored. Any reason why this is silently ignored in flush, > > > rather than > > > being passed up to the caller, or at least being made > > available to the > > > caller? > > > > > > Seems like the the error should be thrown up further rather > > than just > > > ignored. Or at the very least, an error status should be > > > easily readable or > > > returned. > > > > > > Any ideas on this? > > > > > > -Stuart- > > > > > > > -----Original Message----- > > > > From: Stuart Donaldson > > > > Sent: Friday, November 01, 2002 10:03 AM > > > > To: Webware Discussion (E-mail) > > > > Subject: [Webware-discuss] Server Push detecting when the > > client has > > > > gone away. > > > > > > > > > > > > I tried the PushServlet, and am having problems when the > > > > client goes away. > > > > > > > > Basically the client web browser can break the connection by > > > > going on to > > > > another URL, or even just closing down. The PushServlet > > > > doesn't get any > > > > notification of this effect, and just keeps happily > running until > > > > completion. > > > > > > > > Any ideas on where to look for a solution to this? I am > > > > using mod_webkit, > > > > is the status that the connection is closed even passed > > > > through from Apache > > > > into Webware? > > > > > > > > Stuart Donaldson > > > > Alerton Technologies Inc. > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > This sf.net email is sponsored by: See the NEW Palm > > > > Tungsten T handheld. Power & Color in a compact size! > > > > http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en > > > > _______________________________________________ > > > > Webware-discuss mailing list > > > > Web...@li... > > > > https://lists.sourceforge.net/lists/listinfo/webware-discuss > > > > > > > > > > > > > ------------------------------------------------------- > > > This sf.net email is sponsored by: See the NEW Palm > > > Tungsten T handheld. Power & Color in a compact size! > > > http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en > > > _______________________________________________ > > > Webware-discuss mailing list > > > Web...@li... > > > https://lists.sourceforge.net/lists/listinfo/webware-discuss > > > > > > > > ------------------------------------------------------- > This sf.net email is sponsored by: > With Great Power, Comes Great Responsibility > Learn to use your power at OSDN's High Performance Computing Channel > http://hpc.devchannel.org/ > _______________________________________________ > Webware-discuss mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/webware-discuss > |
From: Geoffrey T. <gta...@na...> - 2002-12-13 15:50:36
|
The question is, will anyone's code break if we modify flush() so that it can raise an exception? I doubt it. I say, go ahead and make a patch for this. We do need to clearly document the changed semantics of flush() in the release notes though. - Geoff > -----Original Message----- > From: Stuart Donaldson [mailto:st...@al...] > Sent: Friday, December 13, 2002 9:59 AM > To: Stuart Donaldson; Geoffrey Talvola; Webware Discussion (E-mail) > Subject: RE: [Webware-discuss] Server Push detecting when the > client has > g one away. > > > Ok, I hate it when that happens... I just figured out > something wrong with my suggestion not 2 minutes after I > sent it off ;-( > > To prevent unnecessary logging of closed sockets, > it looks like we would also need to catch the exception in > Application::dispatchRequest(). > > Perhaps raising an exception such as AbortResponse which > could be added, and when caught just cancels the transaction > elements cleanly. The argument to the exception could > continue to be the actual exception reason for aborting. > > -S- > > > > -----Original Message----- > > From: Stuart Donaldson > > Sent: Friday, December 13, 2002 6:47 AM > > To: 'Geoffrey Talvola'; Webware Discussion (E-mail) > > Subject: RE: [Webware-discuss] Server Push detecting when the > > client has > > g one away. > > > > > > I'm looking at this issue again, since I need to resolve it > > for a project. > > > > Current behavior of TASASStreamOut::flush() when the > > connection has been > > closed, is to silently ignore the errno.EPIPE condition when > > flushing data > > to the socket, and will at most print an error line on stdout > > for any other > > errors. Server push applications don't detect the error, > and happily > > continue pushing data to nowhere. > > > > Do we really need to make raising an error when the stream > > can't be flushed > > a conditional operation? Under what conditions would you not > > want to do > > this? The only thing I can think of, is that existing > > applications might > > see the error and generate a log message of some sort? > > > > If we do need to make it conditional, I would prefer not to > > add an argument > > to flush(), but rather to make it a property on the output > > stream. Adding > > an argument to flush would add code on every flush() call, > > while checking a > > property on the stream need only be done when an error occurs. > > > > Another option might be to update the semantics of flush() > to return a > > success/failure code. However that would change the return > > code meaning > > from ASStreamOut::flush() where it means we can send to > > TASASStreamOut::flush() where it mean we did not encounter > any errors. > > Unless a normalized meaning of this can be established, it > > probably should > > not be done this way. > > > > If we raise an exception, Geoff suggested raising an > > exception similar to > > EndResponse. How about a subclass of EndResponse such that existing > > handlers for EndResponse would continue to catch the > > exception normally, but > > a caller could specifically catch the error. > > > > As I said, I need a fix. I have a solution which works for > > me, but would > > prefer to have a solution that would be acceptable in Webware. > > > > Can we just do the following: > > > > class EndResponseSocketError(EndResponse): > > pass > > ... > > > > class TASASStreamOut(ASStreamOut): > > ... > > def flush(self): > > ... > > try: > > sent = sent + self._socket.send(...) > > except socket.error, e: > > raise EndResponseSocketError(e) > > > > What do you think? > > > > -Stuart- > > > > > -----Original Message----- > > > From: Geoffrey Talvola [mailto:gta...@na...] > > > Sent: Friday, November 01, 2002 11:40 AM > > > To: Stuart Donaldson; Webware Discussion (E-mail) > > > Subject: RE: [Webware-discuss] Server Push detecting when the > > > client has > > > g one away. > > > > > > > > > I think that a broken pipe during TASASStreamOut.flush() > > > should cause an > > > exception to be raised, similar to the EndResponse exception in > > > Application.py, that would just gracefully stop further > processing. > > > > > > This would be a change from the current behavior, so it might > > > break existing > > > applications. Does anyone think that would be a big problem? > > > Perhaps this > > > new behavior should only be enabled if you call > > > response.flush(endResponseOnBrokenPipe=1) (or just > > > response.flush(1) for > > > short). > > > > > > - Geoff > > > > > > > -----Original Message----- > > > > From: Stuart Donaldson [mailto:st...@al...] > > > > Sent: Friday, November 01, 2002 1:23 PM > > > > To: Stuart Donaldson; Webware Discussion (E-mail) > > > > Subject: RE: [Webware-discuss] Server Push detecting when the > > > > client has > > > > g one away. > > > > > > > > > > > > Ok, managed to get somewhere on my own here. Apparently in > > > > TASASStreamOut.flush() there is a Broken Pipe error being > > caught and > > > > ignored. Any reason why this is silently ignored in flush, > > > > rather than > > > > being passed up to the caller, or at least being made > > > available to the > > > > caller? > > > > > > > > Seems like the the error should be thrown up further rather > > > than just > > > > ignored. Or at the very least, an error status should be > > > > easily readable or > > > > returned. > > > > > > > > Any ideas on this? > > > > > > > > -Stuart- > > > > > > > > > -----Original Message----- > > > > > From: Stuart Donaldson > > > > > Sent: Friday, November 01, 2002 10:03 AM > > > > > To: Webware Discussion (E-mail) > > > > > Subject: [Webware-discuss] Server Push detecting when the > > > client has > > > > > gone away. > > > > > > > > > > > > > > > I tried the PushServlet, and am having problems when the > > > > > client goes away. > > > > > > > > > > Basically the client web browser can break the connection by > > > > > going on to > > > > > another URL, or even just closing down. The PushServlet > > > > > doesn't get any > > > > > notification of this effect, and just keeps happily > > running until > > > > > completion. > > > > > > > > > > Any ideas on where to look for a solution to this? I am > > > > > using mod_webkit, > > > > > is the status that the connection is closed even passed > > > > > through from Apache > > > > > into Webware? > > > > > > > > > > Stuart Donaldson > > > > > Alerton Technologies Inc. > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > > This sf.net email is sponsored by: See the NEW Palm > > > > > Tungsten T handheld. Power & Color in a compact size! > > > > > http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en > > > > > _______________________________________________ > > > > > Webware-discuss mailing list > > > > > Web...@li... > > > > > https://lists.sourceforge.net/lists/listinfo/webware-discuss > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > This sf.net email is sponsored by: See the NEW Palm > > > > Tungsten T handheld. Power & Color in a compact size! > > > > http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en > > > > _______________________________________________ > > > > Webware-discuss mailing list > > > > Web...@li... > > > > https://lists.sourceforge.net/lists/listinfo/webware-discuss > > > > > > > > > > > > > ------------------------------------------------------- > > This sf.net email is sponsored by: > > With Great Power, Comes Great Responsibility > > Learn to use your power at OSDN's High Performance Computing Channel > > http://hpc.devchannel.org/ > > _______________________________________________ > > Webware-discuss mailing list > > Web...@li... > > https://lists.sourceforge.net/lists/listinfo/webware-discuss > > > |