Increase concurrency level to 40+ threads

[azuread]

Increase concurrency level to 40+ threads

[bgavrilMS]

CC @jmprieur for this important bug

[jmprieur]

@bgavrilMS can we priortize for next release that will get along with MSAL.NET 4.23.0?

[bgavrilMS]

@yihezkel - is this a common scenario to have 150 threads do this work?

We've done some stress testing in the past and found that the current approach fails at around ~10-20 threads on Mac and Linux. We've tested Windows as well but haven't found an upper bound, although we may have not tested with 150 threads.

Petro had some thoughts on how to improve but I do not know if 150 threads can be achieved.

[yihezkel]

Quick note - this was discussed offline

[jmprieur]

@yihezkel : I was not part of the offline conversation. what was discussed/decided? is this still an issue?

[bgavrilMS]

This is still an issue, and we should fix it at some point by using read locks as well as write locks. I marked it as P2 because the use case is not common - around 150 threads running concurrently. But it is not extreme, since an SDK can be used for parallel calls.

[bgavrilMS]

This token caching library is meant to be used in public client scenarios, such as desktop clients, which should not exibit this level of concurrency. If you require this level of concurrency I suggest you experiment with using a different syncronization mechanism. When this library was designed, we chose to use file locks because they are ubiquitous and we have not found alternatives that would easily work across the 3 OSes. I do not think this requirements has changed.

[yihezkel]

I suggest this limitation/assumption be documented. For example, https://github.com/AzureAD/microsoft-authentication-extensions-for-dotnet/wiki/Cross-platform-Token-Cache only says that one of the goals is "Token cache storage can be accessed by multiple processes concurrently.", which is true but with a qualification.

[bgavrilMS]

We will not be fixing this as most public client use a single / a few thread to get tokens. Nobody else complained about this.

If Kusto has a complex scenario requiring many threads, I recommend you use MSAL's lower level cache extensibility to build your own cache, for example an in-memory cache that periodically saves data a file.

Or, if you have a solution for fixing the existing one, please contribute. This project is quite simple.