[JAVA-2797] Ordered w:0 Bulk Writes payload failure behaviour Created: 28/Feb/18 Updated: 26/Nov/18 Resolved: 26/Nov/18 |
|
| Status: | Closed |
| Project: | Java Driver |
| Component/s: | Write Operations |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Ross Lawley | Assignee: | Unassigned |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
Currently, split payloads are all sent w:0, so if the first batch errors a second batch is sent. This is different to single batch behaviour in that ordered bulk writes stop on error. |
| Comments |
| Comment by Ian Whalen (Inactive) [ 26/Nov/18 ] |
|
Closing as Won't Fix because this is an uncommon use case in which users would not know the difference in the failure modes anyway. The fix here is also likely to be complicated. |
| Comment by Robert Stam [ 05/Mar/18 ] |
|
I'm in the process of handling it... not yet fully implemented. The plan is to find the { w : 0 } in the encoded message and overwrite the 0 with a 1. Since the number of bytes isn't changing it's possible to do the overwrite in place. The lower layer should not have to know anything about higher layer concerns (like batch splitting and overriding write concerns), so I plan to add a EncodingPostProcessor delegate to the ComandMessage class that will be called by the MessageEncoder after it has encoded the message. The EncodingPostProcessor can take any actions necessary to override the contents of the already encoded message. This is similar to going back and overriding the moreToCome flag after the fact, and not that different from backpatching document and array sizes after the fact. |
| Comment by Jeffrey Yemin [ 05/Mar/18 ] |
|
I see. It doesn't seem like we can fix this without a change to the Connection API, since the write concern is just part of the command and MixedBulkWriteOperation doesn't know whether it's the last batch. How are you handling this in the C# driver, Robert? |
| Comment by Robert Stam [ 05/Mar/18 ] |
|
I was describing the OP_MSG scenario. The moreToComeFlag in the message header and the { w : n } value in the command should be in agreement. In particular, for ordered unacknowledged writes that have to be split over multiple batches:
Although a similar argument applies to OP_INSERT/UPDATE/DELETE. |
| Comment by Jeffrey Yemin [ 28/Feb/18 ] |
|
Is this the case for the OP_MSG code path, the OP_INSERT/UPDATE/DELETE code path, or both? |