Conversation
in every measurement. This removes the need for an extra lock for every measurement It should also not be depending on a time interval, but on the number of failures detected. Not counting number of failures since it would need to modify the destination or list of at runtime. It should be done in a future refactor. Fixes bug #28897. Bugfix v0.3.0
Add methods to store consecutive destination failures and retrieve the destinations that are still functional. Since destinations can fail because of Tor circuits, it's not count individual failures but consecutives one. Also exit with error if there are no functional destinations left. The maximum number of consecuitve failures is set to 10, but it may need to be changed depending on the percentage of circuits and requests that fail.
teor2345
left a comment
teor2345
left a comment
There was a problem hiding this comment.
This code looks good.
Here are the design changes I think it might need:
- sbws should be able to recover if the network fails for a short time, then starts working again. Recovery should work if one destination fails, and if all destinations fail.
- operators might want to configure MAXIMUM_NUMBER_DESTINATION_FAILURES
What do you think?
I think that we should open other ticket to implement that in other milestone. If you agree, then i'd change the other issues. |
Ok, can you open a ticket in sbws 1.1 to make destinations recover? Since destinations will fail forever in 1.0, let's make the default MAXIMUM_NUMBER_DESTINATION_FAILURES equal to 100. |
#29589
ok, done. |
We can close this PR after you review fixups. |
|
The fixups seem fine to me. Closing because #339 is newer. |
2 participants
No description provided.