-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
f3cb3ae
Compare
// such that any connections returned to the pool to be cached will be disposed of. In such | ||
// a case, we also remove the pool from the set of pools to avoid a leak. | ||
foreach (KeyValuePair<HttpConnectionKey, HttpConnectionPool> entry in _pools) | ||
try |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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. |
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 |
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