Erik,
I can't explain why this condition is holding (when a read is pending, closing
the socket stream has no effect until the timeout expires, all client side).
I would stick with your solution:
| server client |
server := ZnWebSocket startServerOn: 1701 do: [ :webSocket |
[ webSocket runWith: [ :message | Transcript show: 'Received message: ',
message
printString; cr ] ]
on: ConnectionClosed, PrimitiveFailed do: [ "ignore close" ].
Transcript show: 'The server websocket is closed @ ' , DateAndTime now
asString; cr ].
client := ZnWebSocket to: 'ws://localhost:1701'.
[
[ client runWith: [ :message | "ignore received messages" ] ]
on: ConnectionClosed, PrimitiveFailed do: [ "ignore close" ].
Transcript show: 'The client websocket is closed @ ' , DateAndTime now
asString; cr.
server stop ] fork.
10 milliSeconds wait.
client sendMessage: 'Hello world! #' , 999 atRandom asString.
"client close."
"Workaround: use the following instead of 'client close'."
client sendFrame: ZnWebSocketFrame close.
{ server. client }.
I checked and no resources are lost at the end (the socket/stream gets cleaned
up).
I would lower the timeout in any case, 30s is way too long, I would go for 5s
or 10s.
Sven
> On 5 Jun 2020, at 09:55, Erik Stel <erik.s...@gmail.com> wrote:
>
> Hi Sven,
>
> (I hope this message does arrive. Sorry for the late reply. I have not been
> able to use the browser-interface for the ML for a number of days now. An
> admin could not figure this out either. So resorting to actually using a mail
> ;-)
>
> My architecture is one in which client and server are working fairly
> independent. A client or server can send the other a message whenever it
> wants (and there is no response expected). The client is responsible for
> setting up the connection and keeping it ‘open’ (for the server to reach the
> client). When the client wants it can however disconnect and reconnect at a
> later time. The server will still be there (this is not visible in the
> example of course). Both client and server keep track of messages which can’t
> be sent when the connection is (temporarily) down.
>
> So I have to have a separate process to read messages from the process that
> writes messages to the WebSocket. In a test I discovered that closing the
> connection from the client did not get noticed in the process doing the
> reading. I’d like that process to stop running fairly directly since it is
> performing some additional logic. Now it takes a timeout. Closing the
> connection using the specified workaround does get noticed and works for me.
> But I’m unsure if this is a good approach and there’s the risk it will not
> work on a next update. A shorter timeout could be a solution but does mean
> I’m going into a ‘polling’ mode. So I think I prefer my workaround over
> setting a very short timeout.
>
> If you have a better solution though, please let me know.
>
> Kind regards,
> Erik
>
>
