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

[Bob Arning]

  Announcements are not an issue in my case (unless they are lurking 
under a different name somewhere).

Cheers,
Bob

On 8/20/10 9:51 AM, Robert Sirois wrote:
> Here's a couple posts from before.
>
> http://lists.squeakfoundation.org/pipermail/seaside/2010-July/023793.html
>
> I still have this problem regularly... I wanna say Announcements have 
> something to do with it as well? Or maybe it's just by virtue of 
> refreshing.
>
> RS
>
> ------------------------------------------------------------------------
> Date: Fri, 20 Aug 2010 06:00:39 -0400
> From: arning at charm.net
> To: seaside at lists.squeakfoundation.org
> Subject: Re: [Seaside] Re: Connection Closed failure - should 
> something handle this?
>
> FWIW, this happens in non-Pharo Squeak as well. Sometimes 3 or 4 in 
> rapid succession.
>
> Cheers,
> Bob
>
> On 8/20/10 3:47 AM, Lukas Renggli wrote:
>
>     Hi Tim,
>
>     This could be due to a change in the Sockets in Pharo, that's maybe
>     why other people do not see it. It is definitely a bug to get
>     debuggers.
>
>     I don't have time to investigate further right now, but I guess
>     somebody will come up with a fix quickly :-)
>
>     Lukas
>
>     On 20 August 2010 09:44, Nick Ager<nick.ager at gmail.com>  <mailto:nick.ager at gmail.com>  wrote:
>
>         Hi Tim,
>
>
>             Still - it would seem that by signalling this - it could happen, and
>             something should catch it?
>
>             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?
>
>         It doesn't prevent the walkback, but makes sure that "socket destroy" is
>         called. Experiment with:
>         [Error signal] ifCurtailed: [Transcript show: 'Abandoned'; cr].
>         Transcript show: 'Proceeded'; cr
>         from the  excellent exception PBE draft
>         chapter:https://gforge.inria.fr/frs/download.php/26600/PBE2-Exceptions-2010-03-02.pdf
>         Nick
>         _______________________________________________
>         seaside mailing list
>         seaside at lists.squeakfoundation.org  <mailto:seaside at lists.squeakfoundation.org>
>         http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>
>
>
> _______________________________________________ seaside mailing list 
> seaside at lists.squeakfoundation.org 
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>
>
> _______________________________________________
> seaside mailing list
> seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside/attachments/20100820/3393cc3d/attachment.htm