[SERVER-3024] distributed lock will not unlock self Created: 29/Apr/11 Updated: 12/Jul/16 Resolved: 04/May/11 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | 1.9.0 |
| Fix Version/s: | 1.9.1 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Greg Studer | Assignee: | Greg Studer |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Operating System: | ALL |
| Participants: |
| Description |
|
If a distributed lock fails to unlock for some reason ( server connectivity, for example ), the process continues to ping for the lock (so it can't be forced). see CS-541 Assuming mongos is still in a sane state, it should be possible to reacquire distributed locks of the same process and name for singleton threads like the balancer. |
| Comments |
| Comment by auto [ 04/May/11 ] |
|
Author: {u'login': u'gregstuder', u'name': u'gregs', u'email': u'greg@10gen.com'}Message: Re-entrant distributed locks with ping unlock retries – Retries unlock when process is still up but config server has gone down, |
| Comment by Greg Studer [ 04/May/11 ] |
|
Think the real solution here is to make the lock poll on failure to unlock, using the same thread that establishes the legitimacy of the lock. Otherwise single processes which run very infrequently may still block other processes if they fail to unlock. Have a fix which does this as well. Testing for current process is still needed for |