Fork
The Fork action is used to play actions in a different execution thread to the current one. This execution thread is parallel to the main chain used by the Virtual User. When the current iteration of the Virtual User stops, all the threads created using Fork actions in the Actions Container are immediately halted.
In particular, this action can be used to modelize automatic actions played by the browser while the Virtual User is using the web application normally. For example, an action could play every x seconds on the server to refresh a web component (Ajax, Flash plug-in...). This request must be made in parallel to the standard scenario for the Virtual User.
Fork-type logical actions may be shared among several User Paths. See Shared Containers.
When the option Create a local copy of existing variable values is:
- unchecked (by default): existing values of variables are accessed by reference. When a variable value is modified in another thread, the modified value is used by the Fork action.
- checked: existing values of variables are copied locally. When a variable value is modified in another thread, the variable value remains unchanged in the Fork action.
Variables declared after the Fork is created are accessed by reference by the Fork whatever the option selected.
Variables
When NeoLoad variables are used inside a Fork, they are shared for reading in all the execution threads. This ensures communication of variables between the main execution thread and multiple secondary execution threads.
If, in due course, two execution threads modify the same variable, each of the threads obtains its own variable. This allows the use of the same variable extractors derived from the Framework parameters in several execution threads without having to worry about clashing values.
Lastly, in the case of same variables used in different execution threads, variables visibility is based on hierarchy: a Fork can access variables that have been modified locally by its parent until such time as it modifies them itself.
Limitations
When checking a User Path, the actions played as part of a Fork action appear in the list at the moment they are executed. This can make reading the validation results more complicated, as the list will contain several overlapping execution threads.
Execution threads persistence
In the Actions Container, the execution threads created using fork actions are halted when the Container execution is complete. Every Virtual User iteration recreates new paralleled execution threads distinctively.
In the Init Container, the persistence of the execution threads created using Fork actions is subordinated to the configuration of the Actions Container:
- When the Emulate new browser between each iteration option is checked, the execution threads in the Init Container are halted when the first iteration execution is complete. Stopping the browser is simulated.
- When the Emulate new browser between each iteration option is cleared, the execution threads in the Init Container persist all along the User lifetime.
To make an execution thread persistent until the Virtual User stops, the fork logical action must be set in the Init Container, and the Emulate new browser between each iteration option must be cleared for the Actions Container.