[SERVER-13204] Improve racy noPassthroughWithMongod/indexbg*.js tests Created: 14/Mar/14  Updated: 20/Nov/20  Resolved: 17/May/16

Status: Closed
Project: Core Server
Component/s: Testing Infrastructure
Affects Version/s: 2.6.0-rc1
Fix Version/s: 3.3.8

Type: Bug Priority: Minor - P4
Reporter: Randolph Tan Assignee: Vincent Do
Resolution: Done Votes: 0
Labels: todo_in_code
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by SERVER-24064 Fix indexbg_restart_sigkill_secondary... Closed
Related
related to SERVER-52995 Improve racy indexbg_interrupts.js Backlog
related to SERVER-13214 Temporarily restore indexbg*.js test ... Closed
related to SERVER-13215 Move racy indexbg* tests back to repl... Closed
related to SERVER-38301 improve racy indexbg_drop.js test Closed
related to SERVER-24070 Make index_delete.js not timing depen... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Participants:

 Description   

These tests inserts a huge number of documents, initiates a background index build and tries to perform another task in parallel while the background index task is active. The problem is that this is timing dependent and the current test setup tries to achieve this by inserting insane amount of documents.

This is also true for index_delete.js



 Comments   
Comment by Githook User [ 17/May/16 ]

Author:

{u'username': u'vincentdo', u'name': u'Vincent Do', u'email': u'do.vincent@live.com'}

Message: SERVER-13204 Make indexbg tests not timing dependent
Branch: master
https://github.com/mongodb/mongo/commit/ddd5b1de8048e2af238dea2d62e925c5a2f6e283

Comment by Vincent Do [ 05/May/16 ]

This ticket will handle indexbg_restart_secondary and indexbg_restart_sigkill_secondary_noretry since they utilize the same failpoint created in SERVER-23510. index_delete will be handled in SERVER-24070 since it needs a different failpoint to handle its test scenario.

Comment by Eric Milkie [ 14/Mar/14 ]

slowWeekly/indexbg*.js have this same issue, although they keep retrying with larger and larger data sizes until the test processing takes a minimum number of seconds.

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