Blocked Action detection

The performance testing execution engine provides the capability of detecting that an Action is blocked. The definition of blocked is provided by the author of the Action. The definition is provided as an amount of time an Engine Worker Thread is allowed to be unresponsive in the course of executing the Action before it is considered blocked. The performance testing execution engine logs the detection of blocked actions at level FINEST in the Problem Determination Log. In the simplest case, the run would be hung, and discovery of the blocked action would come from examining the Problem Determination log after clicking Stop to end the run.

In addition to detecting blocked actions, a protocol can be notified that the action is blocked. A reference to the blocked Eengine thread is provided with the action, making it possible for a protocol to send a message to the blocked thread. Upon notification of an action being blocked, the protocol can retry the action, finish the action and move to the next action, or finish the virtual user execution.

The IKAction interface will provide the following method as an entry point for protocols to react to a blocked action condition:

public void blocked(). The KAction object state, upon entering blocked(), is potentially corrupted. The protocol writer must assume any or all data associated with the Action is not safe. Also, any locks which may have been held during execute() have been released.

public long getBlockedTimeout()

Returns the action blocked timeout value. Default is 0, which means block indefinitely

public WorkerThread getWorkerThread()

Returns the Engine WorkerThread executing the action when the blocked state was detected.


The performance testing engine interface has added public boolean createWorker(). The purpose of createWorker() is to allow the sentinel thread monitoring workers to add additional workers in response to having removed workers found executing blocked actions.