[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [qftestJUI] 'DeadlockTimeout' and threads created to run SUT scripts.
Hi Adrian, please try is increasing the value of the option Replay->Timeouts->Timeout for deadlock detection to something beyond what is an acceptable wait for the busy cursor. Best regards, Greg "Adrian Chamberlain" <Adrian.Chamberlain@?.com> writes: > 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 -- Gregor Schmid Gregor.Schmid@?.de Quality First Software GmbH http://www.qfs.de Tulpenstr. 41 Tel: +49 8171 919870 DE-82538 Geretsried Fax: +49 8171 919876