[SERVER-4530] parallel/repl.js test is broken Created: 20/Dec/11  Updated: 11/Jul/16  Resolved: 30/Dec/11

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

Type: Bug Priority: Major - P3
Reporter: Aaron Staple Assignee: Antoine Girbal
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Operating System: ALL
Participants:

 Description   

I believe the test used to run all operations created by the EventGenerator against the master node spawned by the test. (I believe this had been accomplished by setting the db variable explicitly and not running the generated events in new scopes.)

Instead the generated operations now run against the mongod the spawning mongo shell is attached to, if there is one. This causes the test to fail when it attempts to validate collections that should have been created on the master mongod node.



 Comments   
Comment by Antoine Girbal [ 30/Dec/11 ]

each thread is isolated and gets its own js scope (same as ScopedThread).
Hence the db object always gets set to the default mongo.
The host needs to be passed to parallelTester.

Comment by auto [ 30/Dec/11 ]

Author:

{u'login': u'agirbal', u'name': u'agirbal', u'email': u'antoine@10gen.com'}

Message: SERVER-4530: repl.js now uses correct host
Branch: master
https://github.com/mongodb/mongo/commit/2eafe478d667bb2e68410c6709806efe60b0b713

Comment by Aaron Staple [ 25/Dec/11 ]

I haven't looked through the whole history, but it kind of looks like the "SERVER-4258: switch the JS Thread classes to work with v8 isolate" e11df372b0b63187f1feb8ae1339d934b4a0ecb8 commit eliminated the implementation for running the parallel operations in shared scopes. And as a result the threads in the repl tests are attaching to the shell's default db rather than using the db variable configured in the repl test.

Comment by Eliot Horowitz (Inactive) [ 20/Dec/11 ]

Do you know about when it broke?

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