[SERVER-19488] FSM tests - standalone tests invoked through ScopedThread Created: 20/Jul/15 Updated: 06/Dec/22 Resolved: 11/May/20 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Concurrency, Testing Infrastructure |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Jonathan Abrahams | Assignee: | Backlog - Server Tooling and Methods (STM) (Inactive) |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | stm, tig-concurrency | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Assigned Teams: |
Server Tooling & Methods
|
||||||||||||
| Participants: | |||||||||||||
| Description |
|
The FSM (concurrency) tests cannot be invoked to execute from mongo (shell) against a running mongod, through the ScopedThread call, since ScopeThreads will not have a global db variable to use. Defining a db variable before loading fsm_all.js has no effect on other ScopedThreads (created by the FSM framework) because global variables are not shared between ScopeThreads. The FSM framework assumes that a mongod was started by (re)smoke.py if sharding or replication isn't used by relying on the implicit db connection (i.e. fsm_all.js is incompatible with --nodb). This improvement is to Create a new "cluster" type that allows a specific port to be specified and gives that as the host the FSM worker threads will use. |
| Comments |
| Comment by Ryan Timmons [ 11/May/20 ] | ||||
|
Closing as wont-fix to indicate that there is currently no intention of doing this. Please re-open if there is priority for this. Perhaps this change could self-service by an appropriate server team if this is necessary rather than having to go thru the STM prioritization queue. | ||||
| Comment by Jonathan Abrahams [ 20/Jul/15 ] | ||||
|
For now we'll use
There are some complications that make this more time consuming/difficult than planned. |