[SERVER-16996] DistributedLock assumes that if a lock obj exists in the first config, then it is also true for others Created: 22/Jan/15 Updated: 28/Sep/15 Resolved: 28/Sep/15 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | 2.8.0-rc5 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Randolph Tan | Assignee: | Unassigned |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Operating System: | ALL | ||||||||
| Participants: | |||||||||
| Description |
|
There are certain edge cases which can break this assumption, and the lock will be stuck in the state where it can never be acquired again without manual intervention. |
| Comments |
| Comment by Andy Schwerin [ 28/Sep/15 ] |
|
Only applies to legacy SCCC config server protocol, and cannot really be improved in that protocol. This problem should not exist in CSRS clusters ( |