[SERVER-20040] Holders of a ForwardingCatalogManager::ScopedDistLock should not call other methods on ForwardingCatalogManager Created: 19/Aug/15 Updated: 25/Jan/17 Resolved: 02/Sep/15 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | 3.1.8 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Andy Schwerin | Assignee: | Spencer Brody (Inactive) |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Backwards Compatibility: | Fully Compatible |
| Sprint: | Sharding 9 (09/18/15) |
| Participants: |
| Description |
|
Rather than call methods on ForwardingCatalogManager, holders of ForwardingCatalogManager::ScopedDistributedLock that need access to a catalog manager should get a pointer to the correct actual catalog manager by calling a method on their instance of ScopedDistributedLock. Because the FCM::SCD suppresses switching of the actual catalog manager underneath the ForwardingCatalogManager, it is unnecessary to engage FCM's locking and replacement detection. Furthermore, because the FCM::SCD is in scope, another operation on the FCM by the thread holding the FCM::SCD might block indefinitely waiting for the catalog manager to be replaced. This approach will cause operations that hold a ScopedDistributedLock, such as chunk migrations, to fail if the catalog manager needs to be replaced due to upgrade mid migration. |
| Comments |
| Comment by Githook User [ 02/Sep/15 ] |
|
Author: {u'username': u'stbrody', u'name': u'Spencer T Brody', u'email': u'spencer@mongodb.com'}Message: |
| Comment by Githook User [ 02/Sep/15 ] |
|
Author: {u'username': u'stbrody', u'name': u'Spencer T Brody', u'email': u'spencer@mongodb.com'}Message: |
| Comment by Githook User [ 02/Sep/15 ] |
|
Author: {u'username': u'stbrody', u'name': u'Spencer T Brody', u'email': u'spencer@mongodb.com'}Message: |