[SERVER-4978] Robustness: expect possibility of exception creating thread and handle it "gracefully" Created: 15/Feb/12 Updated: 14/Jul/17 Resolved: 14/Jul/17 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Stability |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Tad Marshall | Assignee: | DO NOT USE - Backlog - Platform Team |
| Resolution: | Won't Fix | Votes: | 7 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||
| Participants: | |||||||||
| Description |
|
When a mongod or mongos is being hit with a huge number of connections, it may run into the operating system's limit (configured or other) for creating new threads, and thread creation may fail. For example,
Rather than letting this be an "uncaught" exception, we could catch it, log an explanatory message, close the new connection and stay running. This would be more desirable behavior from the customer's perspective, and should be easy to test during development and in smoke tests. |
| Comments |
| Comment by Mira Carey [ 14/Jul/17 ] |
|
This ticket no longer reflects current behavior (as we've changed thread creation failure to a terminating condition, rather than an uncaught exception condition). Additionally, I'm lumping this in with trapping things like out of memory errors as a condition that one could catch, but we choose not to (preferring stronger invariants in a distributed system) |