[SERVER-76953] Support unordered operations on mongos Created: 09/May/23  Updated: 29/Oct/23  Resolved: 01/Jun/23

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: 7.1.0-rc0

Type: Task Priority: Major - P3
Reporter: Vishnu Kaushik Assignee: Vishnu Kaushik
Resolution: Fixed Votes: 0
Labels: milestone-2
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on SERVER-72792 Implement progress bookkeeping for in... Closed
Assigned Teams:
Replication
Backwards Compatibility: Fully Compatible
Sprint: Repl 2023-05-29, Repl 2023-06-12
Participants:

 Description   

On ordered operations, mongos will stop processing replies on the first error it sees. For unordered operations this is not the case. So mongos expects to get back a number of replies corresponding to the number of operations it sent in the case of unordered operations.

However, for certain kinds of errors such as StaleConfig errors, mongod stops processing operations right away (even for unordered operations) and this violates the contract with mongos. We can solve this by "filling up" the rest of the reply vector with copies of the last error in the case of StaleConfig, etc.

This is currently the model in use by batch write operations.

After this ticket is complete, the unit tests here will need to be altered - they are testing that after a single StaleConfig error, even in unordered operations there are no more reply items. However that will no longer be the case.



 Comments   
Comment by Githook User [ 01/Jun/23 ]

Author:

{'name': 'kauboy26', 'email': 'vishnu.kaushik@mongodb.com', 'username': 'kauboy26'}

Message: SERVER-76953 Support unordered operations on mongos.
Branch: master
https://github.com/mongodb/mongo/commit/d853aab310c2653e9b790dedee5709d6f0d3dfc0

Comment by Vishnu Kaushik [ 26/May/23 ]

What I did was instead of actually duplicating staleness errors, I chose to have mongos interpret the last error as having appeared more than once in the unordered case. Outside of the mongos-mongod interaction I don't think any of our other systems care about whether the result array's size matches the original array's size, so this should be OK.

Comment by Vishnu Kaushik [ 17/May/23 ]

There's also an open question of targeting errors should be handled in the (un)ordered case. Feel free to push this to SERVER-76957 if that's a better place for it.

Generated at Thu Feb 08 06:34:05 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.