[SERVER-53959] Refactor FailPoint::pauseWhileSet Created: 21/Jan/21 Updated: 26/Jan/23 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | Internal Code |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Billy Donahue | Assignee: | Backlog - Service Architecture |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | servicearch-wfbf-day | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Assigned Teams: |
Service Arch
|
| Participants: |
| Description |
|
pauseWhileSet doesn't meet user needs, so a client added pauseWhileSetAndNotCancelled, so it can wait polling on either an Interruptible or a CancelationToken or on the FailPoint shouldFail becoming false. Clearly we can't extend FailPoint every time a client comes up with a new way to stop waiting for something. It's also annoying that the granularity isn't tunable by the caller. The real central value-add of .pauseWhileSet was always that it can check on the FailPoint repeatedly while having its multiple hits count as just one hit in the `nTimes` accounting. This can be abstracted out more gracefully, and we can let the clients provide their own implementations for how to sleep, how to poll, and when to break the loop. |
| Comments |
| Comment by Lauren Lewis (Inactive) [ 18/Mar/22 ] |
|
We haven’t heard back from you for some time, so we're going to close this ticket. If this is still an issue for you, please provide additional information and we will reopen the ticket. |