[SERVER-29387] index_many2.js - use write concern or reduce number of indexes to create. Created: 26/May/17  Updated: 27/Oct/23  Resolved: 10/Jul/17

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

Type: Bug Priority: Major - P3
Reporter: Benety Goh Assignee: Backlog - Replication Team
Resolution: Works as Designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
Assigned Teams:
Replication
Backwards Compatibility: Fully Compatible
Operating System: ALL
Participants:
Linked BF Score: 0

 Description   

This test was written a long time ago before we had the replica set passthrough suites. In a replica set, we should probably consider using a write concern throttle the rate of index creation on a replica set or reduce the number of index creation attempts in the test from 1000 to some number much smaller (eg. 70n in index_many.js)



 Comments   
Comment by Max Hirschhorn [ 04/Jul/17 ]

spencer, per my earlier comment, I don't think there's actually an issue with the index_many2.js test as it will lead to creating only at most 64 indexes. Additionally, the CheckReplDBHash test hook will await replication after each test, so I don't think any kind of back-pressure mechanism is necessary (unless a test were to generate more than 511MB of writes).

I don't think we can easily add a write concern to run only in the replica set passthrough

FTR, it wouldn't be too difficult to have the replica_sets_jscore_passthrough.yml test suite load() a file from the jstests/libs/override_methods/ directory like the read_concern_majority_passthrough.yml test suite does and trigger that behavior.

Comment by Spencer Brody (Inactive) [ 03/Jul/17 ]

So, it looks like the original BF that spawned this ticket is closed as a dupe of a ticket that's closed by a change to resmoke.py behavior. Where does this leave this ticket? Is this still causing issues? Is this something we want to do? I don't think we can easily add a write concern to run only in the replica set passthrough, and I worry about reducing the number of indexes created in a test called 'index_many', although I haven't actually looked at the test. If this isn't causing a build failure anymore I'm tempted to just close this as 'Gone away'.
david.storch max.hirschhorn.

Comment by Max Hirschhorn [ 03/Jun/17 ]

benety.goh, what is the issue with the test attempting to create 1000 indexes on the same collection when the "createIndexes" command is just going to return an error response after the 64th one? (At least until SERVER-12250 gets implemented.)

Generated at Thu Feb 08 04:20:43 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.