Connection pooling approach via tokenProviderAsync

[CER-ChrisA]

Hello,

We are attempting to use a connection pool for the DataverseServiceClient.

Our approach is to pool the token generators. The tokenProviderFunction calls a connection factory which cycles through a list of MSAL ConfidentialClientApplications (CCAs) who then handle token acquisition / caching.

It works in our local vms and it works when deployed, but when we run integration tests via a github runner, there looks to be some contention/locking somewhere.

At first we dug heavily into issues with the way we did the connection factory, but after reading a bit through your issues and discussions, I worry that our general approach to connection pooling may be the issue.

When creating the ServiceClient via DI, we use this

services.AddSingleton<IOrganizationServiceAsync2, ServiceClient>(provider =>
		{
			var config = provider.GetService<IOptions<CrmConfig>>();
			var factory = provider.GetService<IConnectionFactory>();
			var client = new ServiceClient(
				new Uri(config.Value.Resource),
				factory.GetTokenAsync, true, provider.GetService<ILogger<ServiceClient>>())
			{
				MaxRetryCount = 5
			};
			return client;
		});

Could you please offer any feedback on our approach from the point of view of the ServiceClient? (we can chat about the connectionfactory too if need be)

We pool the CRM users as CRM API limits are per user.

[CER-ChrisA]

For those who came here with similar issues, to get this working the github workflow job runner was set to ubuntu-latest-8-cores

We tried with 4-cores but found it timed out intermittently. We will probably split the integration tests so we can use the 4 core runner in parallel jobs

[CER-ChrisA]

Additionally, the MSAL ConfidentialClientApplication does some locking when using shared caches so we suspect that was causing the threads to take so long (but have no proof). Again not an issue in the application itself but when github runner only had two cores it would take a while.