[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. |