PowerBIClient and socket exhaustion in ASP.NET Core app

PowerBIClient is a part of Microsoft.PowerBI.Api package. Developers use it to integrate their apps with PowerBI. There are many sample solutions on the Internet that show how to use it in ASP.NET Core apps. The typical approach is to create a new instance of PowerBIClient and then use it to invoke web requests. Eventually, it is disposed of. Unfortunately, under the hood, it manually creates HttpClient and therefore may lead to socket exhaustion. In this post, we will discuss two alternative options of using PowerBIClient in the ASP.NET Core web app.

What is the problem and what are possible solutions?

The current version of Microsoft.PowerBI.Api (4.2.0) does not allow injecting your own HttpClient into PowerBIClient. There is no constructor that allows doing this. However, there are some overloads that take HttpMessageHandler and DelegatingHandler instances. Furthermore, if you look at PowerBIClient source code you will find out that it derives from ServiceClient<> class. Consequently, wherever PowerBIClient instance is disposed of, its internal HttpClient gets disposed of too together with all HTTP handlers that are referenced by ServiceClient base class.

What can we do? From my research there are two options:

• Register PowerBIClient as a singleton.
• Override internal HttpClient with instance created by IHttpClientFactory.

It used to be quite common to register HttpClient as a singleton. The downside of this approach was that HttpClient did not respond to DNS changes. Since ASP.NET Core 2.1 the suggested solution has been to use IHttpClientFactory which manages an instance of HttpMessageHandler (and therefore connections lifetime).Together with .NET Core 2.1 new SocketsHttpHandler was created. It is the main HttpMessageHandler of every HttpClient instance. Internally it manages connections and reacts to DNS changes by replacing them with new ones.

Both solutions mentioned above are applicable to PowerBIClient and will be presented in this article.

PowerBI API token provider

First of all, both option 1 and option 2 needs to have an API token. I'm going to briefly describe how it works in my application. You can skip this paragraph if you already have it working.

There is a class that implements ITokenProvider interface (PowerBIClient will use it). It acquires tokens from IConfidentialClientApplication (from Microsoft.Identity package) which has client id and client secret of service principal used to authenticate to PowerBI API.

1public interface IPowerBIApiTokenProvider : ITokenProvider { }2
3public class PowerBIApiTokenProvider : IPowerBIApiTokenProvider4{5    private readonly IConfidentialClientApplication _confidentialClientApplication;6    private readonly IList<string> _powerBiScopes;7
8    public PowerBIApiTokenProvider(9        IList<string> powerBiScopes,10        IConfidentialClientApplication confidentialClientApplication)11    {12        _powerBiScopes = powerBiScopes;13        _confidentialClientApplication = confidentialClientApplication;14    }15
16    public async Task<AuthenticationHeaderValue> GetAuthenticationHeaderAsync17        CancellationToken cancellationToken)18    {19        var authenticationResult =20            await _confidentialClientApplication21                .AcquireTokenForClient(_powerBiScopes)22                .ExecuteAsync(cancellationToken);23
24        return new("Bearer", authenticationResult.AccessToken);25    }26}

It is registered as a singleton because IConfidentialClientApplication manages a token cache. I hardcoded (and mocked) service principal data. In real life, I would use IOptions interface to set appropriate values.

1services.AddSingleton<IPowerBIApiTokenProvider, PowerBIApiTokenProvider>(provider =>2{3    var azureTenantSpecificUrl =4        "https://login.microsoftonline.com/myTenant/";5
6    var clientApp = ConfidentialClientApplicationBuilder7        .Create("service principal client id")8        .WithClientSecret("service principal client secret")9        .WithAuthority(azureTenantSpecificUrl)10        .Build();11
12    return new(new List<string>()13    {14        "https://analysis.windows.net/powerbi/api/.default"15    }, clientApp);16});

Option 1 – Registering PowerBIClient as a singleton

Below you can see how to register PowerBIClient as a singleton in the default ASP.NET Core dependency container. In order to log requests with ILogger we need to create LoggingHttpMessageHandler and LoggingScopeHttpMessageHandler to append them to HTTP handlers pipeline. After that, you can inject IPowerBIClient anywhere in your code.

1services.AddSingleton<IPowerBIClient, PowerBIClient>(provider =>2{3    var logger = provider.GetRequiredService<ILogger<PowerBIClient>>();4    var tokenProvider = provider.GetRequiredService<IPowerBIApiTokenProvider>();5    var loggingHandler = new LoggingHttpMessageHandler(logger);6    var loggingScopeHandler = new LoggingScopeHttpMessageHandler(logger);7
8    var httpHandler = new HttpClientHandler();9
10    var client = new PowerBIClient(11        new TokenCredentials(tokenProvider),12        httpHandler, loggingHandler, loggingScopeHandler);13
14    return client;15});

Under the hood, HttpClientHandler creates an instance of SocketsHttpHandler. Unfortunately, HttpClientHandler stores it in a private field, and as a result, it cannot be accessed. There are some properties in SocketsHttpHandler that may be interesting for us.

One of them is PooledConnectionLifetime which defines the maximum lifetime of connection in a pool. By default, it does not have any limit.

Another property is PooledConnectionIdleTimeout. It describes how long it takes to remove the connection from the pool if it is unused. The default value of this is 2 minutes. Consequently, with default settings, if the given connection is used often (more than once per 2 minutes) it will never be recreated. In some scenarios, this may lead to problems with DNS.

In order to fix that we need to use reflection. First of all, let’s create an extension method on HttpClientHandler class that will return a current reference to SocketsHttpHandler.

1public static class HttpClientHandlerExtensions2{3    public static SocketsHttpHandler GetUnderlayingSocketsHttpHandler(4        this HttpClientHandler handler)5    {6        var field = typeof(HttpClientHandler)7            .GetFields(BindingFlags.NonPublic | BindingFlags.Instance)8            .SingleOrDefault(x => x.FieldType == typeof(SocketsHttpHandler));9
10        return field?.GetValue(handler) as SocketsHttpHandler;11    }12}

Then we can modify PowerBIClient factory method. We additionally log an error if for some reason we are not able to get SocketsHttpHandler. It may happen if the internal implementation of HttpClientHandler will change. We set PooledConnectionLifetime to 60 minutes so after this timespan connection will be replaced unless there is a request in progress.

1services.AddSingleton<IPowerBIClient, PowerBIClient>(provider =>2{3    var logger = provider.GetRequiredService<ILogger<PowerBIClient>>();4    var tokenProvider = provider.GetRequiredService<IPowerBIApiTokenProvider>();5    var loggingHandler = new LoggingHttpMessageHandler(logger);6    var loggingScopeHandler = new LoggingScopeHttpMessageHandler(logger);7
8    var httpHandler = new HttpClientHandler();9
10    var socketHandler = httpHandler.GetUnderlayingSocketsHttpHandler();11
12    if (socketHandler == null)13    {14        logger.LogError(15            "SocketsHandler for PowerBIClient is null and has not been configured.");16    }17    else18    {19        socketHandler.PooledConnectionLifetime = TimeSpan.FromMinutes(60);20    }21
22    var client = new PowerBIClient(23        new TokenCredentials(tokenProvider),24        httpHandler, loggingHandler, loggingScopeHandler);25
26    return client;27});

Option 2 – Overriding internal HttpClient

This solution is quite tricky. We need to create a class that derives from PowerBIClient. Thanks to that, we have access to HttpClient which has a protected setter. Then in the constructor, we are able to set our own HttpClient. In our case, this is created by IHttpClientFactory. Unfortunately, we invoke the base constructor first – this is how C# works. It creates HttpClient instance and HttpClientHandler (plus few other delegating handlers). Thus, we need to dispose of them and delete every reference to them. Thanks to that, the garbage collector will get rid of it. Because PowerBIClientWrapper will not have a chance to use these handlers, the connections will not be created in the pool.

1public class PowerBIClientWrapper : PowerBIClient2{3    public PowerBIClientWrapper(4        ServiceClientCredentials credentials,5        HttpClient httpClient) : base(credentials)6    {7        HttpClient?.Dispose();8        FirstMessageHandler?.Dispose();9        HttpClientHandler?.Dispose();10
11        FirstMessageHandler = null;12        HttpClientHandler = null;13
14        HttpClient = httpClient;15    }16}

After that, we need to register HttpClient that will be used by PowerBIClient internally. By default, PowerBIClient uses RetryAfterDelegatingHandler and RetryDelegatingHandler as delegating handlers. The request may fail if there are too many concurrent requests to PowerBI API at a given moment. In this solution, you can define your own retry policy. For simplicity let’s try to replicate default behavior.

1services.AddHttpClient(nameof(PowerBIClientWrapper))2    .ConfigurePrimaryHttpMessageHandler(() =>3    {4        var delegatingHandler = new RetryAfterDelegatingHandler5        {6            InnerHandler = new HttpClientHandler()7        };8
9        return new RetryDelegatingHandler(delegatingHandler);10    });

Then we can register PowerBIClientWrapper as scoped so a new instance will be created for every request. It’s ok for us since now we create HttpClient with IHttpClientFactory. Because PowerBIClientWrapper implements the IPowerBIClient interface, it can be registered under it. Logging will work out of the box.

1services.AddScoped<IPowerBIClient>(provider =>2{3    var tokenProvider = provider.GetRequiredService<IPowerBIApiTokenProvider>();4    var httpClientFactory = provider.GetRequiredService<IHttpClientFactory>();5    var httpClient = httpClientFactory.CreateClient(nameof(PowerBIClientWrapper));6    var client = new PowerBIClientWrapper(new TokenCredentials(tokenProvider), httpClient);7    return client;8});

Although IPowerBIClient and created HttpClient are disposed of after each request the underlaying HTTP handlers are not. That’s because handlers used by HttpClient are not referenced by PowerBIClientWrapper. Furthermore, during HttpClient disposal, these handlers are not touched.

Conclusion

Both options have their drawbacks. Registering PowerBIClient as a singleton requires reflection to configure SocketsHttpHandler. However, it’s a slightly better solution than disposing of already existing HttpClient to replace it with the new one.

Both option one and two resolves the socket exhaustion problem. It’s up to you which one you choose. That would be great if there were a constructor that takes HttpClient in PowerBIClient. I hope that Microsoft will add that eventually.