[Seaside] Re: Connection Closed failure - should something handle this?

[Andreas Raab]

On 8/20/2010 12:15 AM, TimM wrote:
> Kai-Uwe Pielka wrote:
>> I'm running etumma.de with Pharo/Seaside on a debian server for
>> several months now including Comet (for the shared slideshow you can
>> use at etumma.de) and never got this error.
>
> That's good to know - although having this, you may have jinxed
> yourself... and will find 3 tomorrow ;)
>
> Still - it would seem that by signalling this - it could happen, and
> something should catch it?

You are absolutely right. This code is poorly written in the face of 
network issues. The structure is wrong - it starts processing even 
before it's known whether the request can be successfully read, making 
it difficult to signal and handle the error properly. A couple of things 
you can do:

1) Work around the issue by using an error handler in process: along the 
lines of:

WAListenerAdaptor>>process: aRequest
	^[super process: aRequest] on: Error do:[:ex|
		"put your error handling here"
	].

This has the icky side effect that the handler is also in effect for the 
entirety of the Seaside processing cycle which might decidedly not be 
what you want in development.

2) Rewrite WAListenerAdaptor to read the request first instead of in the 
midst of processing (not sure if you're up for that).

3) Help lobbying for 
http://code.google.com/p/seaside/issues/detail?id=591 which would allow 
you to switch out WAListenerAdaptor for something that doesn't have 
these problems.

Cheers,
   - Andreas


>
> Looking again, I see the following method in the stack:
>
> WAListenerAdaptor>>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
>
>
> Shouldn't that ifCurtailed: prevent this walkback?