We're currently working on a way to dump all threads from the current app pool somewhere when an event occurs to narrow down the blocking issue. This is getting fun, processes dumping themselves.
We are definitely calling this method Dumpster.Fire();
After some great work from @m0sa this works - moving to enable this ability in prod: 
@m0sa Just waiting on another occurrence now - we should get a minidump to find the jerk. Connection pool exhaustion we theorize is a red herring on async continuations failing to fire as a symptom of thread pool starvation, not the instigator of the event.
@m0sa It turns out the .NET 5 SDK is eating way more CPU while building than the 3.1 SDK did - we're trying to figure out why. It pegs all cores (github.com/dotnet/sdk/blo…), but perhaps Roslyn wasn't able to peg all cores before. @jaredpar any idea if there were threading changes in 5?
• • •
Missing some Tweet in this thread? You can try to
force a refresh
