Refactors how TelemetryClient connects and sends messages to use a message queue and a separate sending loop thread that sends messages from the queue. This is almost the same implementation as the java-ice-adapter except I added some connection retry logic (java-ice-adapter will only try to reconnect once).
Why
I noticed that the initial register as peer message wasn't getting sent because the connection hadn't been established yet. When I ran in the debugger it was slow enough that it did work which is why I didn't catch this before. This was due to the async future returning immediately since it was usingconnect() rather than connectBlocking(). I think this could be simply fixed by using connectBlocking() but this all got me thinking about reconnecting and what happens if messages are dropped. There was a bit that tried to reconnect when the connection dropped. But, this overwrites the connectingFuture and so any messages waiting on connectingFuture would get dropped (I think) and it wouldn't keep trying to reconnect. I had been hoping to avoid the message queue/sending loop logic in the java implementation but I think it makes sense.
Refactors how
TelemetryClientconnects and sends messages to use a message queue and a separate sending loop thread that sends messages from the queue. This is almost the same implementation as the java-ice-adapter except I added some connection retry logic (java-ice-adapter will only try to reconnect once).Why
I noticed that the initial register as peer message wasn't getting sent because the connection hadn't been established yet. When I ran in the debugger it was slow enough that it did work which is why I didn't catch this before. This was due to the async future returning immediately since it was using
connect()rather thanconnectBlocking(). I think this could be simply fixed by usingconnectBlocking()but this all got me thinking about reconnecting and what happens if messages are dropped. There was a bit that tried to reconnect when the connection dropped. But, this overwrites theconnectingFutureand so any messages waiting onconnectingFuturewould get dropped (I think) and it wouldn't keep trying to reconnect. I had been hoping to avoid the message queue/sending loop logic in the java implementation but I think it makes sense.