[squeak-dev] Resuming a SocketStream after a ConnectionClosed exception?

tim Rowledge tim at rowledge.org
Sat Feb 11 06:01:46 UTC 2017


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....




More information about the Squeak-dev mailing list