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
I believe this is a duplicate of #145 which was closed due to no activity but appears to be unresolved.
I have calls to Apply which sometimes occur at the same time as nodes in the cluster being stopped, e.g. in unit/integration tests. In this situation, waiting on the result from the future returned by Apply (deferError.Error()) will block forever, causing the test to deadlock. This is because deferError is waiting on a response from the errCh which is never going to come.
Interestingly, a change was added a while back to add a ShutdownCh to deferError to allow futures to react to shutdowns. However, this appears to only be used to address a deadlock that occurred when snapshots are taken.
It seems to me like deferError ought to have a timeout on it, either taking its own timeout on calls to Error() or by respecting the timeout passed to Apply(). Given that the future returned by Apply involves RPCs and consensus, it seems like this should have a timeout to prevent potential deadlock situations.
The text was updated successfully, but these errors were encountered:
Hey there,
We wanted to check in on this request since it has been inactive for at least 90 days.
Have you reviewed the latest godocs?
If you think this is still an important issue in the latest version of the Raft library or its documentation please feel let us know and we'll keep it open for investigation.
If there is still no activity on this request in 30 days, we will go ahead and close it.
Thank you!
I believe this is a duplicate of #145 which was closed due to no activity but appears to be unresolved.
I have calls to
Apply
which sometimes occur at the same time as nodes in the cluster being stopped, e.g. in unit/integration tests. In this situation, waiting on the result from the future returned byApply
(deferError.Error()
) will block forever, causing the test to deadlock. This is becausedeferError
is waiting on a response from theerrCh
which is never going to come.Interestingly, a change was added a while back to add a
ShutdownCh
todeferError
to allow futures to react to shutdowns. However, this appears to only be used to address a deadlock that occurred when snapshots are taken.It seems to me like
deferError
ought to have a timeout on it, either taking its own timeout on calls toError()
or by respecting the timeout passed toApply()
. Given that the future returned byApply
involves RPCs and consensus, it seems like this should have a timeout to prevent potential deadlock situations.The text was updated successfully, but these errors were encountered: