Mitigate race condition in EventSource_ConnectionPoolAtMaxConnection_LogsRequestLeftQueue test #55729
Conversation
…_LogsRequestLeftQueue test There is a unavoidable race condition between updating event counters and reading their values in WaitForEventCountersAsync. It waits for at least 2 sets of EventCounter event groups to ensure the last group is captured after any actual work (tests check that counters reset back to 0 if there is nothing happening). Since it looks for `requests-started` which occurs before `http11-requests-queue-duration` event, what it may see is only the tail of the last group and the start of the second, without waiting for a fresh `http11-requests-queue-duration`. In this, the assert `Assert.Equal(0, http11requestQueueDurations[^1])` on the line 549 will see a non-zero counter value and fail. This PR changes the condition to `< 3` to guarantee there is at least one full group of events in the window. Co-authored by @MihaZupan Fixes #46073
|
Tagging subscribers to this area: @dotnet/ncl Issue DetailsThere is a unavoidable race condition between updating event counters and reading their values in WaitForEventCountersAsync. It waits for at least 2 sets of EventCounter event groups to ensure the last group is captured after any actual work (tests check that counters reset back to 0 if there is nothing happening). This PR changes the condition to Co-authored by @MihaZupan Fixes #46073
|
There was a problem hiding this comment.
Thanks for putting up the PR.
cc: @geoffkizer this is the issue I mentioned that is possibly the reason you were seeing EventSource_ConnectionPoolAtMaxConnection_LogsRequestLeftQueue failures locally
|
/azp list |
|
/azp run runtime-libraries-coreclr outerloop |
|
Azure Pipelines successfully started running 1 pipeline(s). |
ghost
locked as resolved and limited conversation to collaborators
There is a unavoidable race condition between updating event counters and reading their values in WaitForEventCountersAsync. It waits for at least 2 sets of EventCounter event groups to ensure the last group is captured after any actual work (tests check that counters reset back to 0 if there is nothing happening).
Since it looks for
requests-startedwhich occurs beforehttp11-requests-queue-durationevent, what it may see is only the tail of the last group and the start of the second, without waiting for a freshhttp11-requests-queue-duration. In this, the assertAssert.Equal(0, http11requestQueueDurations[^1])on the line 549 will see a non-zero counter value and fail.This PR changes the condition to
< 3to guarantee there is at least one full group of events in the window.Co-authored by @MihaZupan
Fixes #46073