[Seaside] Re: Connection Closed failure - should something handle
andreas.raab at gmx.de
Fri Aug 20 16:01:03 UTC 2010
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
^[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
> 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?
More information about the seaside