[SERVER-37056] Blacklist shard_existing_coll_chunk_count.js from last_stable suite Created: 07/Sep/18 Updated: 29/Oct/23 Resolved: 26/Sep/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | 4.1.4 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Matthew Saltz (Inactive) | Assignee: | Janna Golden |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | sharding-wfbf-day | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Backwards Compatibility: | Fully Compatible | ||||
| Operating System: | ALL | ||||
| Sprint: | Sharding 2018-10-08 | ||||
| Participants: | |||||
| Linked BF Score: | 4 | ||||
| Description |
|
In mixed version 4.0/4.2 clusters, both mongos and shards will be triggering autosplits for chunks. In the case of this test, sometimes mongos will trigger a split for a chunk that no longer exists (because of concurrent splits or because its routing info is stale), but when it does this, it prevents the shard from acquiring the dist lock when it attempts to do the split for the chunk we're actually expecting to split. So, the shard gets a LockBusy error on trying to acquire the dist lock, and we don't end up with as many chunks as we were expecting. This behavior is not incorrect, but it is difficult to avoid in this test, so we can just blacklist it for the last stable suite. |
| Comments |
| Comment by Githook User [ 26/Sep/18 ] |
|
Author: {'name': 'jannaerin', 'email': 'golden.janna@gmail.com', 'username': 'jannaerin'}Message: |
| Comment by Githook User [ 26/Sep/18 ] |
|
Author: {'name': 'jannaerin', 'email': 'golden.janna@gmail.com', 'username': 'jannaerin'}Message: |