[SERVER-14327] Bulk API should apply write concern on each legacy operation Created: 20/Jun/14  Updated: 31/Jan/18  Resolved: 10/Apr/17

Status: Closed
Project: Core Server
Component/s: Shell
Affects Version/s: 2.7.2
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Jeremy Mikola Assignee: Randolph Tan
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Backwards Compatibility: Fully Compatible
Operating System: ALL
Participants:

 Description   

The bulk API executes legacy operations through this fucntion, which does not apply a write concern (w:1 will be applied by default).

The full write concern is only applied (i.e. resetError follwed by a GLE) after all legacy operations have executed, here. The decision for applying a write concern at this point is when the user-provided WC is more than w:1 or w:0 and we haven't seen any write errors or we're unordered and have less write errors than the total number of operations.

As-is, the code is optimized for communication with a standalone server or replica set, as punting the WC to the very end avoids throttling of each legacy operation; however, if we're connected to mongos, the final WC may not be sufficient unless it was blasted to all shards (or at least all those involved in previous writes), which I don't believe is the case.



 Comments   
Comment by Randolph Tan [ 10/Apr/17 ]

The current mongos upconverts all legacy writes to write commands before sending to shards so this is no longer an issue.

Comment by Andrew Morrow (Inactive) [ 07/Apr/17 ]

renctan - Based on your last comment, can this be closed given that only affected nodes talking to a 2.4 mongos, which is long since EOL.

Comment by Randolph Tan [ 20/Jun/14 ]

Clarification: I believe this is only an issue when talking to 2.4 mongos.

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