You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In a project we are building, we use RobustConnections to have a reliable way of reestablishing dropped connections. This works great, but sometimes we'd like still like to drop a connection after a certain timeout. For example, if a connection fails to be up after trying to reconnect for 5 minutes, we would like to consider it dead for good and propagate the error condition upwards in our stack. Right now, we use a watchdog task that hooks a RobustConnections close- and reconnect-callbacks to see whether the connection is back up in time, but that feels quite hacky.
I see that #259 adds some kind of global timeout to all operations, but I'm not quite sure if that includes what we'd need (nor do I completely understand the changeset). PR #247 proposes a similar feature, but tries to limit the number of attempts instead of the time taken to establish the connection. Both PRs seem to have stalled; is there a blocker for this where I could help out?
Is there a way this could be implemented easily? I could try and implement the execution timeout and open a pull request, however I do not have the required overview over the library (yet).
The text was updated successfully, but these errors were encountered:
In a project we are building, we use
RobustConnection
s to have a reliable way of reestablishing dropped connections. This works great, but sometimes we'd like still like to drop a connection after a certain timeout. For example, if a connection fails to be up after trying to reconnect for 5 minutes, we would like to consider it dead for good and propagate the error condition upwards in our stack. Right now, we use a watchdog task that hooks aRobustConnection
sclose
- andreconnect
-callbacks to see whether the connection is back up in time, but that feels quite hacky.I see that #259 adds some kind of global timeout to all operations, but I'm not quite sure if that includes what we'd need (nor do I completely understand the changeset). PR #247 proposes a similar feature, but tries to limit the number of attempts instead of the time taken to establish the connection. Both PRs seem to have stalled; is there a blocker for this where I could help out?
Is there a way this could be implemented easily? I could try and implement the execution timeout and open a pull request, however I do not have the required overview over the library (yet).
The text was updated successfully, but these errors were encountered: