[HTTP] Scavange fix #61530
[HTTP] Scavange fix #61530
Conversation
…longer than the timer interval gets triggered
… caller (scavenge timer callback)
|
Tagging subscribers to this area: @dotnet/ncl Issue DetailsDisposes connection in a separate task to not to block the scavenging timer callback on the stream close. I plan to validate the fix with the customer before merging. But I'd like to know if the way I solved this is not completely wrong or too different from what you had in mind? @geoffkizer @stephentoub
|
|
Rather than using a periodic timer and then checking for parallel execution, I would suggest we just use a single-shot timer and reset it in RemoveStalePools after the scavenge pass has completed. |
| // Dispose them asynchronously to not to block the caller on closing the SslStream or NetworkStream. | ||
| if (toDispose is not null) | ||
| { | ||
| Task.Run(() => toDispose.ForEach(c => c.Dispose())); |
There was a problem hiding this comment.
This unnecessarily allocates a closure/delegate even if toDispose is null. That can be avoided with:
| Task.Run(() => toDispose.ForEach(c => c.Dispose())); | |
| Task.Factory.StartNew(s => ((List<HttpConnectionBase>)s!).ForEach(c => c.Dispose()), toDispose, | |
| CancellationToken.None, TaskCreationOptions.DenyChildAttach, TaskScheduler.Default); |
ManickaP
force-pushed
the
mapichov/61505_no_parallel_scavenge
branch
2 times, most recently
from
c9de343 to
f3cb3ae
Compare
There was a problem hiding this comment.
Why was this added?
If it's possible for this code to throw, then it seems like we have a deeper problem here, which is that we could skip cleaning up some pools.
There was a problem hiding this comment.
I'll remove it.
I didn't want to accidentally end up with turned off cleaning timer which never gets restarted.
|
One issue above, otherwise LGTM. |
ManickaP
force-pushed
the
mapichov/61505_no_parallel_scavenge
branch
from
f3cb3ae to
5013728
Compare
|
Customer validated the fix against 6.0 and 5.0. It helped with overlapping callbacks. However, in case of 5.0, they're still seeing abnormal number of |
|
/backport to release/6.0 |
|
Started backporting to release/6.0: https://github.com/dotnet/runtime/actions/runs/1498779065 |
ghost
locked as resolved and limited conversation to collaborators
4 participants
Disposes connection in a separate task to not to block the scavenging timer callback on the stream close.
Guards scavenging timer callback from parallel execution.
Fixes #61505
Fixes #61506
I plan to validate the fix with the customer before merging. But I'd like to know if the way I solved this is not completely wrong or too different from what you had in mind? @geoffkizer @stephentoub