Before the retry maybe do...
* a Delay; and/or
* a garbage collection; and/or
* assign a new SocketStream to the socket stream variable

cheers -ben

On Sat, Feb 11, 2017 at 2:01 PM, tim Rowledge <tim at rowledge.org> wrote:
> My MQTT stuff needs to handle the occasional ConnectionClosed type error.
>
> I don’t see anything in SocketStream code that suggests any sort of reconnect, and indeed the ConnectionClosed exception is non-resumable. What on earth does one do when a socket dies?
>
> My two i/o loops are basically  just
> [[outboundSharedQueue next outputOn: socketStream] repeat]
> and
> [[self handleIncoming: (MQTTPacket readFrom: socketStream)] repeat]
> forked off as separate processes.
>
> The socketStream can raise the ConnectionClosed when either doing the #next as part of the reading, or  in the #nextPut: whilst writing; obviously. Right now I’m trying to make it work with  the read process modified to
>
> [[[packet := [MQTTPacket readFrom: socketStream] on: NetworkError do:[:e|
>         some stuff to reconnect.
>         e retry].
> self handleIncoming: packet] repeat] forkThing
>
> What ought to happen is the socket stream gets reconnected/replaced, the MQTT connection is re-established and then the [MQTTPacket readFrom: socketStream] is restarted. There’s some extra fun for dealing with interrupted multi-part handshaking sequences too, but that’s a different colour of fish-kettle.
>
> Clearly the ‘some stuff to reconnect’ is not currently doing the job I thought it was since it doesn’t seem to reconnect and hookup again. I’m beginning to think that I ought to suspend the other process before doing the reconnect, and also that I’ve stared at this so much I’m not seeing the wood for the trees.
>
> I’m not picking up any particular inspiration from WebClient or WebServer and haven’t googled into anything that seems relevant. Any ideas out there?
>
> tim
> --
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> How many of you believe in telekinesis? Raise my hands....
>
>
>