runtime: Investigate whether we can speed up handler cleanup when app is not receiving traffic

See discussion here: https://github.com/aspnet/AspNetCore/issues/3470#issuecomment-455001937

@acds reported that there was an ongoing message handler cleanup cycle with only a few handlers. This is somewhat normal since we can only collect a handler if it’s eligible to be collected (because the HttpClient instances have been GC’ed.

However in this case the app didn’t have any traffic going to it and this was causing issues because:

The issues is it’s in a Triggered Azure WebJob that fails with a timeout as it has not completed that clean up after the requisite 120 seconds. This can be extended but it seems that switched to a continuous job it continues to clean up for the hour to the next scheduled trigger. Burning up resources for nothing than letting the Job sleep.

We should investigate what we can do for cases like this where HttpClient factory is being used in a short-running scenario.

About this issue

Original URL
State: open
Created 5 years ago
Comments: 15 (6 by maintainers)

Most upvoted comments

I am terribly sorry for barging in on a distantly connected issue, but I was trying to find a follow up on aspnet/HttpClientFactory#165, which was created from dotnet/aspnetcore#3470, which in turn led to this issue, and they are all closed for comments, and I really don’t think it merits an issue in itself.

Now, I fully understand what @davidfowl says:

The logs seem indicate that things are never going out of scope and hence the supposed leak. What’s happening is the timer that is used to expire the handler has a reference to a callback which seemingly keeps the HttpMessageHandler alive.

When a GC happens things are cleaned up as expected. Until then, the background scanner will keep looping until that happens.

But I still am worried: if for some reason GC doesn’t clean things up for some time, I might end up having quite a few of handlers linked there being undisposed. Wouldn’t that pose an issue with socket exhaustion, which was one of the original reasons for reusing the handlers? Especially that I am on .net 4.8, not Core, so I don’t have access to SocketsHttpHandler.

srogovtsev on Jun 19, 2020