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.