[Pharo-project] Correct usage of exception handlers with ensure and ifCurtailed
Hi, I have an issue with WAListenerAdapter throwing ConnectionTimeOut and ConnectionClosed exceptions in a headless image, which causes the VM to abort. 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. Thanks. -- ~JT
On Mon, Oct 24, 2011 at 9:13 AM, John Toohey <jt@parspro.com> 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
- 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 <eliot.miranda@gmail.com> wrote:
On Mon, Oct 24, 2011 at 9:13 AM, John Toohey <jt@parspro.com> 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
On 25 October 2011 22:13, John Toohey <jt@parspro.com> wrote:
- 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.
Absolutely, WA..Adapter should handle such situations, or at least let user to handle them in a way he prefers to. But since this code related to Seaside, i guess you should open a discussion in seaside mailing list otherwise there are big chances that it will remain like today, because this code outside of pharo developers responsibility. -- Best regards, Igor Stasenko.
participants (3)
-
Eliot Miranda -
Igor Stasenko -
John Toohey