- Yes it quits, not aborts. The issue is that the WAListenerAdapter throws ConnectionTimedOut exceptions, and in the headless state, these un-handled exceptions cause the VM to shutdown. My Seaside app has a custom Exception handler registered for the app, but its not called here.
This code is from the WAListenerAdapter, so all I want to do is catch the exception and ignore it. Sockets timing out in a web app is not an exception. The stack trace runs from the Socket class back to the WAListenerAdapter class, so that is why I wanted to put a handler there. The code is the original code from that class. In the context of my web app, a socket timing out is not exceptional, so all I want to for the code to clean up after itself, and accept back on the socket. I was hoping that the handler that I put it would be sufficient, but your comments on the background process it making me wonder. On Tue, Oct 25, 2011 at 14:04, Eliot Miranda <[email protected]> wrote: > > > On Mon, Oct 24, 2011 at 9:13 AM, John Toohey <[email protected]> wrote: >> >> Hi, >> I have an issue with WAListenerAdapter throwing ConnectionTimeOut and >> ConnectionClosed exceptions in a headless image, which causes the VM >> to abort. > > I doubt that the VM aborts. I expect the headless unhandled exception > handler quits the system. > >> >> These "exceptions" are just socket timeouts, and can be >> ignored. >> >> The methods that I believe is the correct place to handle these is >> coded as follows :- >> >> waitForConnection: aSocket >> | socket stream | >> socket := aSocket waitForAcceptFor: 10. >> socket isNil ifTrue: [ ^ self ]. >> stream := SocketStream on: socket. >> [ [ [ self process: stream ] >> ensure: [ stream close ] ] >> ifCurtailed: [ socket destroy ] ] >> forkAt: Processor userBackgroundPriority >> >> I've changed the code so it looks like this :- >> >> waitForConnection: aSocket >> | socket stream | >> socket := aSocket waitForAcceptFor: 10. >> socket isNil ifTrue: [ ^ self ]. >> stream := SocketStream on: socket. >> [ [ [ [self process: stream ] >> on: NetworkError >> do:[:ex| ^self]] >> ensure: [ stream close ] ] >> ifCurtailed: [ socket destroy ] ] >> forkAt: Processor userBackgroundPriority >> >> As the errors are intermittent and only occur on my production server, >> I wonder is someone can look at the code, and tell me if I've added >> the #on:do: block correctly. > > What is the error that is raised? You should see some info in > SqueakDebug.log or some such. Also I think tat using userBackgroundPriority > here as I suspect as it would conflict with the background process. I would > use userBackgroundPriority 1. However, if process: passes on the socket to > some other process and the error is raised in the context of that process > then your exception handler in your background process isn't going to handle > it. > Some things to try: > - examine the backtrace in SqueakDebug.log (and if you don't get one look at > the system's headless error handler and make sure it gives you a back > trace). > - last resort, run the VM in gdb, put a breakpoint in e.g. exit and then > call printCallStack() or printAllStacks() to see what's going on at the > point of exit. > HTH >> >> Thanks. >> -- >> ~JT >> > > > > -- > best, > Eliot > -- ~JT
