OPERATIONAL DEFECT DATABASE
...
...
BugZero found this defect 2565 days ago.
The functions defined with the $config object of an FSM workload are executed by multiple threads in the following way: 1. The $config.setup() function is executed once by the main thread. 2. The $config.states functions are executed $config.iterations times by each the worker threads. 3. The $config.teardown() function is executed by the main thread. The changes from SERVER-30681 made it so a session is started with causal consistency enabled for each of the FSM worker threads. The changes from SERVER-30682 made it so that a readPreference of "secondary" is used, which made it possible for the $config.setup() function to do a write to the primary and for a $config.states function to do a read from a secondary. The main thread must forward its operationTime and clusterTime after #1 to each of the worker threads to ensure that a read from secondary will wait until the write has been applied.
xgen-internal-githook commented on Sun, 15 Oct 2017 01:56:18 +0000: Author: {'email': 'max.hirschhorn@mongodb.com', 'name': 'Max Hirschhorn', 'username': 'visemet'} Message: SERVER-31456 Set initial {Cluster,Operation} Time in concurrency suite. Ensures that the FSM worker threads are guaranteed to observe the effects of the $config.setup() function being called since they'll specify an afterClusterTime beyond that point. Branch: master https://github.com/mongodb/mongo/commit/0ed1b71a50b45b93f0952e1482643c0d9216731d xgen-internal-githook commented on Sun, 15 Oct 2017 01:56:17 +0000: Author: {'email': 'max.hirschhorn@mongodb.com', 'name': 'Max Hirschhorn', 'username': 'visemet'} Message: SERVER-31456 Expose server type on Mongo connection object. This makes it possible to prevent the mongo shell from gossiping a clusterTime to stand-alone mongod processes when the mongo shell is also connected to a replica set or a sharded cluster. Branch: master https://github.com/mongodb/mongo/commit/2c5511c8c411c70ac1063d1209764e71f83d0b1a
