[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 – SERVER-3024

Retries unlock when process is still up but config server has gone down,
in case of errors during locking and unlocking. Also allows testing
of locks already held.
Branch: master
https://github.com/mongodb/mongo/commit/ad01e102a8b766c8a2fe0cfc09f3fccd5e3b53c5

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 SERVER-3039.

Generated at Thu Feb 08 03:01:51 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.