[CSHARP-2115] Highly contested startup doesn't resolve itself properly Created: 29/Nov/17 Updated: 27/Oct/23 Resolved: 25/Jan/19 |
|
| Status: | Closed |
| Project: | C# Driver |
| Component/s: | Connectivity |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Craig Wilson | Assignee: | Robert Stam |
| Resolution: | Works as Designed | Votes: | 1 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
||||||||||||
| Issue Links: |
|
||||||||||||
| Description |
|
Not sure how to state this differently than the title. If we startup with 100 tasks (threads) on a non-discovered cluster, discovery takes longer to complete causing some (or all) of the requests to fail. There is something going on with a highly contested startup, likely as it relates to SDAM. |
| Comments |
| Comment by Robert Stam [ 25/Jan/19 ] |
|
I was unable to reproduce this at first, until I managed to get my hands on the original test program. Turns out the original test program was using Task.Run to simulate async over sync, which is not recommended. If you create enough Tasks that all end up blocking they end up consuming all the threads from the pool that the async machinery uses to run Tasks. In our case, all those blocked Tasks were preventing the driver's own heartbeat Tasks from running and therefore interfering with server discovery and monitoring. If you run the attached test program you can confirm that the test runs fine with either 1000 pure sync Threads or 1000 pure async Tasks. But even only 100 fake async Tasks is enough to jam up the thread pool. So the workaround for this issue is to either use 100% pure sync calls or 100% pure async calls, but don't try to fake async over sync. One interesting article about mis-using Task.Run this way is: https://blog.stephencleary.com/2013/11/taskrun-etiquette-examples-using.html
|