[SERVER-44257] sharding/findandmodify2 needs to wait for enableAutosplit take effect on mongos Created: 25/Oct/19  Updated: 16/Apr/20  Resolved: 16/Apr/20

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

Type: Bug Priority: Major - P3
Reporter: Misha Tyulenev Assignee: Tommaso Tocci
Resolution: Won't Fix Votes: 0
Labels: sharding-wfbf-day
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Operating System: ALL
Sprint: Sharding 2019-12-16, Sharding 2019-12-30, Sharding 2020-04-20
Participants:
Linked BF Score: 10

 Description   

The test exposes a race condition in sharding test where the enableAutosplit parameter updates the config database after the mongos has been started and hence it can miss the enableAutosplit value.

This does not seem to be a serious issue but caused the BF-15172. To fix it may make sure that the autosplit is enabled in the sharding/findandmodify2.js test before running the workload



 Comments   
Comment by Tommaso Tocci [ 16/Apr/20 ]

As misha.tyulenev said, the problem is that ShardingTest is starting first the router then the config servers and then the shards. This means that when the mongos starts it doesn't know that the autosplit needs to be enabled and it will fetch that configuration parameter from the config server later on through the sharding uptime reporter thread.

In 4.0 the autosplitter was operating on the mongos, on 4.2 on both mongos and the shards and as of 4.4, the autosplitter is operating only on the shards. This explain why this test failed just once in the 4.2 branch and only on the sharding_last_stable_mongos_and_mixed_shards suite. In fact in this specific scenario the router is running with v4.0 and is in charge for the autosplitting.

Given that this issue:
 - Doesn't affect any version grater then 4.0.
 - Is not a problem on production system.
 - There is not an easy fix for this and all the solution I discussed with matthew.saltz required a lot of changes or dirty hacks.

We decided not to fix this.

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