[SERVER-26667] Legacy SCCC dist lock race during first lock acquisition Created: 17/Oct/16 Updated: 06/Dec/22 Resolved: 29/Dec/16 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | 3.2.10 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Randolph Tan | 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 | ||
| Issue Links: |
|
||||
| Assigned Teams: |
Sharding
|
||||
| Operating System: | ALL | ||||
| Sprint: | Sharding 2016-11-21, Sharding 2016-12-12, Sharding 2017-01-02 | ||||
| Participants: | |||||
| Linked BF Score: | 0 | ||||
| Description |
|
Here's the hypothetical scenario: 1. Thread 1 sees that the lock document does not exist and tries to create it. C1: unlocked, owned by nobody 2. Thread 2 comes in and sees on the first config the the lock is in unlocked state and tries to grab it by sending updates to 3 config servers. 3. However, since the update is upsert: false, it will only succeed in updating the first one. C1: locked, owned by thread 2 4. Since thread 2 failed to update to all 3 config servers, it will enter the tournament round which will then fail immediately because the lock document does not exist on the other config servers. |
| Comments |
| Comment by Kaloian Manassiev [ 29/Dec/16 ] |
|
With SCCC deprecated and since this is not a correctness problem, but just a rare nuisance at mongos startup, we won't fix this bug. |