Sockets are low-level beasts and should simply do what they are told and raise errors when the can't do so. Client and server abstractions on top of that are the soonest that one should think about timeouts and retries (and the latter is really an application level decision). These wrappers will indeed want to handle various errors to keep things clean, perhaps subsequently triggering events/notifications that something happened.
________________________________________ From: [email protected] [[email protected]] On Behalf Of John Toohey [[email protected]] Sent: Monday, October 10, 2011 10:18 PM To: [email protected] Subject: Re: [Pharo-project] Socket timeout terminates COG VM I think the main source of the exceptions is in the WAListenerAdapter in the #process: aNativeRequest (Implemented in WAServerAdapter) My app uses Comet so I need a streaming server. I've wrapped an exception handler around this, and am testing now. Overall I think that the socket code, if it is going to detect timeouts, it should retry and the just close and cleanup that socket. If the calling app ever calls on that socket, then an exception should be thrown, and in this case, the app would be expecting it. On Mon, Oct 10, 2011 at 21:34, Schwab,Wilhelm K <[email protected]> wrote: > Not knowing what exception this is, I'm not sure whether to agree or argue. > However, given the importance of error handling to robust network apps, it > should get handled. > > > > ________________________________________ > From: [email protected] > [[email protected]] On Behalf Of Igor Stasenko > [[email protected]] > Sent: Monday, October 10, 2011 7:05 PM > To: [email protected] > Subject: Re: [Pharo-project] Socket timeout terminates COG VM > > On 11 October 2011 01:27, Schwab,Wilhelm K <[email protected]> wrote: >> John, >> >> No question, the punishment certainly exceeds the crime :) I was making a >> general plea for what I really believe is the correct way to build network >> software. >> > So you prefer leaving an image in some undefined state, potentially > leaking system resources, > because of unhandled exception which nobody cares to handle? > At best what you can have then is, when your critical process will > enter an endless error-producing loop > is just bogging all system resources or hanging an image, without > giving you any idea what's going on. > So , if you prefer such kind of punishment for your crimes, just use > image prior to 1.3 and be happy :) > >> Bill >> >> >> >> >> ________________________________________ >> From: [email protected] >> [[email protected]] On Behalf Of John Toohey >> [[email protected]] >> Sent: Monday, October 10, 2011 5:24 PM >> To: [email protected] >> Subject: Re: [Pharo-project] Socket timeout terminates COG VM >> >> The exception is not coming from my code, if it was I could trap it. >> Regardless, isn't shutting the VM down a bit of overkill in this case? >> >> On Mon, Oct 10, 2011 at 17:12, Igor Stasenko <[email protected]> wrote: >>> On 10 October 2011 23:19, John Toohey <[email protected]> wrote: >>>> Hi, >>>> >>>> I've had a problem since 1.0 with socket timeouts throwing exceptions >>>> and invoking the debugger in my headless images. I don't know why a >>>> socket timeout is considered exceptional, but I've gotten used to >>>> using VNC to log into the server and close the debuger windows. >>>> However, I've moved to COG and the latest one-click images, and now >>>> the error terminates the VM. >>>> >>>> My app is a standard Seaside server, using the streaming connector for >>>> Comet support. >>>> >>>> I've attached the PharoDebug.log. It would be appreciated if anyone >>>> could help me with this problem, as I'm at a loss where to even begin. >>>> >>> >>> So, just put an exception handler, and handle this exception in a >>> manner you want >>> and then your image will keep working! :) >>> >>>> >>>> Using Pharo1.3 #13298 on Lucid32 (Ubuntu) >>>> >>>> >>>> -- >>>> ~JT >>>> >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >>> >> >> >> >> -- >> ~JT >> >> >> > > > > -- > Best regards, > Igor Stasenko. > > > -- ~JT
