`sharding/remove2.js` is waiting for the ReplicaSetMonitor timeout in order to be able re-add a shard after its removal.
Instead of waiting 60s for the RSM to be removed from the interesting nodes, pols the connectionsPoolStats of these nodes until it is actually removed.
The new polling approach is reducing the test execution time on Enterprise RHEL 6.2 run time form ~2:40 to ~1:40
This commit also unblacklist the sharding/remove2.js test from the multiversion suites. Because the new polling approach solves BF-17247.
This patch does the following:
- Fixes a use-after-move scenario with operationKey.
- Alters the cancelation pattern to kill remotely first, then locally.
- Initializes the requestManager and timer members in the
CommandState*::make() function.
- Uses the existing mutex to synchronize connection resolution and
cancelation.
- Attempts to bind std::shared_ptr<RequestState> only to the request
path.
ref: 90a2282276..32b5f903db
for: 4.5.1
WT-5679 Set the oldest history store checkpoint timestamp as oldest timestamp during restart
WT-6083 Enable row-store tables in checkpoint-test
WT-6148 Add new update to the history store with valid stop timestamp
WT-6177 Fix direct I/O configurations failure combined with mmap configurations
WT-6190 Review time window validation
WT-6222 Never append prepared update in __rec_append_orig_value
WT-6223 Insert a full value into history store if the newer update is a prepared update
WT-6224 Adding a globally visible tombstone when an on disk prepared update is rolled back
WT-6227 Fix testutil macro usage and add block backup to smoke.sh
WT-6235 Change operation order of prepared commit and rollback
WT-6242 Set flag on prepared updates when they're restored from disk
WT-6245 Handle aborting prepared onpage tombstones
WT-6246 Cleanup stop timestamp and pass the correct timestamp to the cell
WT-6247 Fix modify visibility in history store
WT-6252 Remove mutable read timestamp from transaction structure
WT-6253 Fix time window validation for out of order timestamps
The InProgressLookup tracking already has quite complicated logic, so it
seems prudent to pull it into a separate class, outside of the
ReadThroughCache so it can be tested independently.
After yielding and reacquiring locks in a query, the preconditions that were used to select our
ReadSource initially need to be checked again. Queries hold an AutoGetCollectionForRead RAII
lock for their lifetime, which may select a ReadSource based on state (e.g. replication
state). After a query yields its locks, this state may have changed, invalidating our current
choice of ReadSource.
ref: 4cf221a61f..90a2282276
for: 4.5.1
WT-6042 Changes to checkpoint04 to remove or debug failures on Windows
WT-6165 Fix cursor operation hung on WT_PREPARE_CONFLICT
WT-6173 Change __wt_time_window_ functions to macros
WT-6174 Fix dhandle->session_inuse counter leak in __evict_walk
WT-6195 Ensure that we don't perform rollback to stable without a history store
WT-6214 format.sh must disassociate from the child process
"-workers auto" automatically detects available parallelism,
"OffHeapDiskFPSet" uses a concurrency optimised fingerprint set, and
ExecutionStatisticsCollector sends usage stats to exec-stats.tlapl.us
Closes #1361
Signed-off-by: A. Jesse Jiryu Davis <jesse@mongodb.com>
