[SERVER-15808] audit re-enabled yielding paths for sharding Created: 27/Oct/14  Updated: 02/Aug/18  Resolved: 17/Nov/14

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: 2.7.8
Fix Version/s: 2.8.0-rc1

Type: Task Priority: Major - P3
Reporter: Greg Studer Assignee: Gregory McKeon (Inactive)
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to SERVER-15141 stale config error flattened when thr... Closed
Tested
Participants:

 Description   

With cursor yielding re-enabled and significant concurrency changes, revisit the places where contexts are acquired to be sure that shard version information is correctly handled.



 Comments   
Comment by Greg Studer [ 17/Nov/14 ]

Fixes in SERVER-15541.

Comment by Greg Studer [ 28/Oct/14 ]

Upshot of the audit is:

Update/Delete:
We should probably throw StaleConfigExceptions (SCEs) for non-multi updates and single deletes. We can then easily have consistent behavior with DeadlockExceptions which are effectively forced yields. EDIT: Currently works similarly to v2.6.

Count:
We may need to throw SCEs when yielding during count to preserve our (bad) behavior.

FileMD5:
Doesn't yield - so either we remove internal version check entirely (some dead code here) or we enable yielding and the version check.

GeoNear:
Going to be deprecated, but if simple should also throw SCE now that geoNear doesn't do all the work at once.

FindAndModify:
Should throw SCE on yielding since these are always non-multi/single update/delete operations. EDIT: Currently works similarly to v2.6.

Other commands preserve previous behavior.

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