[SERVER-21310] Inject iterations and threadCount into data object in fsm workloads Created: 05/Nov/15 Updated: 18/Nov/15 Resolved: 10/Nov/15 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Testing Infrastructure |
| Affects Version/s: | None |
| Fix Version/s: | 3.2.0-rc3 |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Judah Schvimer | Assignee: | Judah Schvimer |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||
| Sprint: | TIG C (11/20/15) | ||||||||||||
| Participants: | |||||||||||||
| Description |
|
Currently threadCount and iterations aren't available as part of the "this" context for workloads. Thus, workloads that use these as parameters can only access what they're set to initially. When using the load multiplier, any workloads that use the initial versions of these parameters fail because the threadCount has changed from what they expect. If they could just look at data for the updated threadCount, they could pass again. |
| Comments |
| Comment by Githook User [ 10/Nov/15 ] |
|
Author: {u'username': u'judahschvimer', u'name': u'Judah Schvimer', u'email': u'judah@mongodb.com'}Message: |
| Comment by Kamran K. [ 05/Nov/15 ] |
|
Sounds good to me. |
| Comment by Max Hirschhorn [ 05/Nov/15 ] |
|
Could we do that and also define a setter for the property that throws an error? |
| Comment by Kamran K. [ 05/Nov/15 ] |
|
I was thinking we could just define non-enumerable, non-configurable, non-writable properties to avoid namespacing. One drawback is that assignments will silently fail. |
| Comment by Max Hirschhorn [ 05/Nov/15 ] |
|
What's the plan for "namespacing" the iterations and threadCount properties to distinguish them from properties that the workload may set while it is running? |