[SERVER-46981] The MongoS write commands scheduler does not account for the potential size of the response BSON Created: 19/Mar/20  Updated: 29/Oct/23  Resolved: 06/Apr/20

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: 4.2.4, 4.0.17
Fix Version/s: 4.7.0

Type: Bug Priority: Major - P3
Reporter: Kaloian Manassiev Assignee: Kaloian Manassiev
Resolution: Fixed Votes: 0
Labels: PM-1645-Milestone-1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on SERVER-47170 Make the NSTargeter not mix exception... Closed
is depended on by SERVER-46703 Make a variant of checkShardVersionOr... Closed
Related
related to SERVER-47210 The StaleShardVersion error response ... Backlog
Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: Sharding 2020-03-23, Sharding 2020-04-06, Sharding 2020-04-20
Participants:

 Description   

When constructing the batch insert/update/delete command to send to shards, the MongoS write commands scheduler (aka BatchWriteExecutor), accounts for the size of the outgoing request, so it doesn't exceed the 16MB BSON size limit on the way out. However, this doesn't guarantee that the response, which gets generated by the shard will not exceed that size.

This is usually not problematic for ordered=true batches or for smallerĀ ordered=false batches. However for larger ordered=false batches, because of the way the writeErrors is generated, the response can grow to be much larger than the request.

As an example, a batch insert of 100.000 entries which encounters a StaleShardVersion, will result in this kind of situation.



 Comments   
Comment by Githook User [ 06/Apr/20 ]

Author:

{'name': 'Kaloian Manassiev', 'email': 'kaloian.manassiev@mongodb.com', 'username': 'kaloianm'}

Message: SERVER-46981 Make the BatchWriteExecutor account for the potential size of the error response
Branch: master
https://github.com/mongodb/mongo/commit/1d6cd3e2fbe7b31fab7c6d2dc73587c40ec66d56

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