[SERVER-21937] Calculate write concern and distlock timeouts for talking to the config servers relative to the electionTimeout for the config replica set Created: 17/Dec/15 Updated: 06/Dec/22 Resolved: 13/Apr/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Replication, Sharding |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Spencer Brody (Inactive) | Assignee: | [DO NOT USE] Backlog - Sharding Team |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Assigned Teams: |
Sharding
|
| Operating System: | ALL |
| Participants: |
| Description |
|
As part of |
| Comments |
| Comment by Kaloian Manassiev [ 17/Dec/15 ] |
|
When you say that these longer timeouts may "lead to slower error detection", do you mean in the pathological cases where primary cannot be elected at all? Because in the normal case where a primary is elected faster than 10 seconds, the timeouts which we selected make no difference. For the pathological case, they do not make error detection by clients much slower either, because we have an upper bound on the number of retries, which in the absence of master will fail very quickly. So, in my opinion there is no need to link the distributed lock and the wait for config write concern timeouts with the replication's election timeout. |