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
