[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[qftestJUI] 'DeadlockTimeout' and threads created to run SUT scripts.
Hi, If during the execution of an SUT script, QF-Test throws a 'DeadlockTimeout' exception, would you expect QF-Test to end the execution of that SUT script and release its associated thread ? Basically, I have a procedure named 'WaitOnBusyCursor', which will not return until the cursor type is no longer 'java.awt.Cursor.WAIT_CURSOR' (i.e. the glass pane is not visible). File: common.qft Package: common Procedure: waitOnBusyCursor (See attached file: common.qft) This procedure takes 3 parameters :- Parameter 1: interval Parameter 2: frameWndComponentid Parameter 3: breakOnNotActiveWnd The 'interval' parameter specifies the delay to apply between successive calls to get the cursor type associated with the window frame identified by the parameter 'frameWndComponentid'. This is to ensure that the loop within the SUT script does not soak up an excessive amount of CPU time. The boolean parameter 'breakOnNotActiveWnd' simply provides a mechanism, whereby the caller can ensure that the procedure returns, if the window is no longer the active window (this would happen, if for instance, an 'Error' dialog box were to pop-up). The procedure works very well. However, there is a situation where a dialog window (i.e. Realign Element Manager) takes a considerable amount of time to perform its operation, during which time the hour glass cursor will be visible whenever the mouse pointer is moved over that dialog box (i.e. cursor type is java.awt.Cursor.WAIT_CURSOR). A call to the procedure 'waitOnBusyCursor' is made so as to allow our test-suite will wait until that operation has completed. I am finding that after a few minutes QF-Test reports a 'DeadlockTimeout' exception. I am trying to understand what is leading to this 'DeadlockTimeout' exception in the hope of finding a solution that will prevent the dead lock occurring in the first place. The following run log shows the SUT script within the procedure 'waitOnBusyCursor' was excepted by a 'DeadlockTimeout' exception after approx. 2 mins. (See attached file: MV38TestAutomation.qrz) The above leads me to ask the following questions. QF-Test displays a dialog box warning of a possible deadlock. The test-run has come to an end (i.e. the QF-Test <Start test run> toolbar button is once again enabled i.e. dark green). At this stage I would have expected that the SUT script is no longer running (i.e. its associated thread has been released). However, I noticed that diagnostic output (from the print statements in the SUT script) were still appearing in the QF-Test 'Terminal' window (i.e. the clients standard output). In other-words, the SUT script was still running on its associated thread. Should execution of the SUT script have ended, given that the procedure call had been terminated as a result of a 'DeadlockTimeout' exception ? I am simply curious to know if this is correct behaviour for QF-Test, or perhaps a bug ? Ultimately, is it at all possible to amend my script/procedure in any way, in order to avoid the possibility of a 'DeadlockTimeout' exception occurring. Thank you in advance for any help. Regards Adrian