[DOCS-8935] Do not retry findAndModify operations on MMAPv1 Created: 28/Sep/16  Updated: 30/Oct/23

Status: Closed
Project: Documentation
Component/s: Server
Affects Version/s: None
Fix Version/s: Server_Docs_20231030

Type: Task Priority: Major - P3
Reporter: Emily Hall Assignee: Unassigned
Resolution: Won't Do Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Documented
documents SERVER-22002 Do not retry findAndModify operations... Closed
Participants:
Days since reply: 1 year, 14 weeks, 2 days ago
Epic Link: DOCSP-1769

 Description   

If a findAndModify command requests a sort, we pass a limit of 1 to that sort so that it will only keep track of the top document, reducing it's memory footprint.

This can lead to lots of retrying when there are many findAndModify operations which all specify a sort and are trying to update the same document, which is a common pattern for some sort of work queue.

What happens is that each findAndModify operation will chug along doing it's sort (I think this is only a problem if it's an in-memory sort, not an index-provided sort), each one periodically yielding, and one will eventually finish first and update the document. Each other operation will eventually find that the matching document has already been modified, so cannot update it themselves. Since there was a limit of 1, the sort stage does not have the next matching document, and the operations have to restart, and re-sort everything.

This is particularly bad on MMAPv1, since the updates have to take an exclusive lock on the collection. The logic to retry operations on MMAPv1 was only introduced in SERVER-21434. We should revert this change, instead allowing clients to continue to retry (as they likely are already).

As part of this work, it was discovered that there are cases where we do not retry the operation, even on WiredTiger. We should fix those places as well.



 Comments   
Comment by Education Bot [ 31/Oct/22 ]

Hello! This ticket has been closed due to inactivity. If you believe this ticket is still important, please reopen it and leave a comment to explain why. Thank you!

Generated at Thu Feb 08 07:57:16 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.