The commits in this pull request add simple reconnection logic to the SOSClient so that observations are less likely to be lost when there are network issues or periods of inactivity that cause closed connections. (This improves the functionality of the SWEVirtualSensor, which uses the SOSClient under the hood.)
Note that these changes are still not a perfect solution for every use case. Observations that occur during an outage will not be transferred when the reconnection succeeds.
The connections (either websocket or plain http) managed by SOSClient are performed in a background thread. This has the side-effect of making the SWEVirtualSensor always start immediately (rather than having to wait for an initial response). Almost all exceptions or errors that occur are logged, and then a reconnection is scheduled. Only 401/403 errors will cause a failure that results in the sensor being stopped.
The commits in this pull request add simple reconnection logic to the SOSClient so that observations are less likely to be lost when there are network issues or periods of inactivity that cause closed connections. (This improves the functionality of the SWEVirtualSensor, which uses the SOSClient under the hood.)
Note that these changes are still not a perfect solution for every use case. Observations that occur during an outage will not be transferred when the reconnection succeeds.
The connections (either websocket or plain http) managed by SOSClient are performed in a background thread. This has the side-effect of making the SWEVirtualSensor always start immediately (rather than having to wait for an initial response). Almost all exceptions or errors that occur are logged, and then a reconnection is scheduled. Only 401/403 errors will cause a failure that results in the sensor being stopped.