search

qmsk / e2

E2 Client, Tally output
Mozilla Public License 2.0
26 stars 7 forks source link

WebSocket reconnects #12

Open SpComb opened 8 years ago

SpComb commented 8 years ago

If the backend encounters an connection error, it will crash, and if running as a systemd service, restart. Currently, the frontend UI will detect the websocket close, and freeze the UI into an error state.

It should instead reconnect once the server comes back up.

This is particularly important for the e2-server, as it does not manage any E2 connection state and will error out if disconnected from the E2. See https://github.com/qmsk/e2/issues/6#issuecomment-246582103

I spoke too soon... after exactly five minutes the server crashed

2016/09/12 22:04:42 xmlClient.read: update
2016/09/12 22:04:42 client:TCPClient 192.168.1.27: recv: []string{"\x04ATRN", "-e", "0"}
2016/09/12 22:09:43 xmlClient.read: read tcp4 192.168.1.25:40214->192.168.1.27:9876: i/o timeout
2016/09/12 22:09:43 server.Run: xmlClient.Read: read tcp4 192.168.1.25:40214->192.168.1.27:9876: i/o timeout

That's a timeout error on the XML connection. Did your network connection between the rpi server and your E2 break?

The tally binary handles E2 client disconnects by waiting for it to reappear. The server code is far more simple and only handles a single E2 client, and it exits if the client disconnects.

ATM this "crash fast" behaviour is more or less intentional, and you should use something like systemd to restart the service. The server itself is stateless, so it's more or less the same end result as handling reconnects within the code. Just far simpler than implementing the reconnect code.