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

  • all batches but the last need to override moreToComeFlag to 0 and the write concern to { w : 1 }
  • the last batch should have moreToComeFlag equal to 1 and the write concern equal to { w : 0 }

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?

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