[SERVER-20784] Ensure that the concurrency suite actually awaits replication between workloads Created: 06/Oct/15 Updated: 15/Oct/15 Resolved: 08/Oct/15 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Testing Infrastructure |
| Affects Version/s: | 3.1.8 |
| Fix Version/s: | 3.2.0-rc0 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Kamran K. | Assignee: | Jonathan Abrahams |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Backwards Compatibility: | Fully Compatible |
| Sprint: | TIG A (10/09/15) |
| Participants: |
| Description |
|
As milkie pointed out, it's possible for the writeConcern write in jstests/concurrency/fsm_libs/cluster.js to fail to run if a failover is occurring and there's no primary:
We should fail with a clear error message if the branch is not executed at all (because of a transient lack of a primary). |
| Comments |
| Comment by Githook User [ 08/Oct/15 ] |
|
Author: {u'username': u'hptabster', u'name': u'Jonathan Abrahams', u'email': u'jonathan@mongodb.com'}Message: |
| Comment by Kamran K. [ 06/Oct/15 ] |
|
Actually, the simpler fix here is to just use the connection to the primary and not run isMaster(). The code will need to be updated to handle sharded replica sets, as well. Also, we should probably just use the built-in ReplSetTest.awaitReplication method instead of using a replicated write. |