[SERVER-30195] Increase connection pool timeout for administrative pools Created: 17/Jul/17 Updated: 08/Jan/24 Resolved: 17/Aug/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Internal Code |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Mira Carey | Assignee: | Mira Carey |
| Resolution: | Won't Fix | Votes: | 5 |
| Labels: | former-quick-wins, neweng, service_architecture | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||
| Participants: | |||||||||||||||||
| Case: | (copied to CRM) | ||||||||||||||||
| Description |
|
The network interface's in administrative pools should have substantially longer connection timeouts than the default, due to sharing of pools with very intermittent use. I believe the interesting set to be:
|
| Comments |
| Comment by Mira Carey [ 17/Aug/18 ] |
|
Closing this as wont fix, as I think the better long term solution is to re-architect the excessive number of TaskExecutors into a smaller set which share networking and use an unlimited ThreadPool backend. |
| Comment by Andy Schwerin [ 18/Jul/17 ] |
|
So that's 2 pools for replication (NetworkInterfaceASIO-Replication and NetworkInterfaeASIO-RS), and 5 for sharding (the rest). The two instances in replication should ultimately be combined, now that they're both instances of ThreadPoolTaskExecutor (as of Interestingly, none of the sharding executors except the AddShard one actually use the asio networking. They use TaskExecutor for work scheduling. AddShard's executor is only used for contacting replica sets that aren't yet in a sharded cluster to bring them into the fold, so can't be affecting steady state performance. |