Uh oh!
There was an error while loading. Please reload this page.
[HTTP] Scavange fix - #61530
Conversation
…longer than the timer interval gets triggered
… caller (scavenge timer callback)
ghost
commented
Nov 12, 2021
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
|
geoffkizer
commented
Nov 12, 2021
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); |
c9de343 to
f3cb3aeCompareThere 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.
geoffkizer
commented
Nov 15, 2021
One issue above, otherwise LGTM. |
f3cb3ae to
5013728CompareManickaP
commented
Nov 22, 2021
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 |
ManickaP
commented
Nov 24, 2021
/backport to release/6.0 |
Started backporting to release/6.0: https://github.com/dotnet/runtime/actions/runs/1498779065 |
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