Print a heartbeat to RQG output to avoid wrapper timeouts

Registered by John H. Embretsen

When the RQG is run under certain conditions, for example as part of a larger test execution framework, generating a certain amount of output within certain intervals may be looked at as a sign of liveliness. That is, if no output is generated for, say, 30 minutes, the wrapping framework may abort the test even though it is still running as intended. This blueprint specifies adding a monitor to the RQG allowing messages to be printed to the output with the purpose of keeping the test run alive.

Blueprint information

Status:
Not started
Approver:
None
Priority:
Undefined
Drafter:
John H. Embretsen
Direction:
Needs approval
Assignee:
None
Definition:
New
Series goal:
None
Implementation:
Unknown
Milestone target:
None

Related branches

Sprints

Whiteboard

The basic idea is to print a heartbeat message at regular intervals, generating activity on standard out.
Example message:

"RQG Heartbeat - a harmless message to avoid test timeouts under certain conditions"

Due to Perl's inherent limitations when it comes to threads and forking, especially on Windows, we try to avoid using this in the RQG.

RQG Reporters are implemented so that they are polled each 10 seconds. After doing whatever it needs to do, a reporter must return control to the caller as soon as possible, to allow other Reporters (monitors) to run as well.

Note that all Monitors are ran sequentially, so by sleeping() in your monitor for x minutes you prevent any other monitors from being executed during this time. The monitor() function is called every 10 seconds.

The correct way to code this would be to record the timestamp of your last heartbeat message and output a new one if enough time has elapsed since. If not enough time has elapsed, return STATUS_OK to allow other Reporters to run as well.

You may use an existing GenTest::Reporter:: module as a model for the structure (uses, subs) to use.

A suggestion for extended functionality is to print the MySQL Processlist or some such instead of a fixed text, to allow more advanced debugging in case of "silent" tests.

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.

Subscribers

No subscribers.