Mailingliste - Einträge 2006

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [qftestJUI] 'DeadlockTimeout' and threads created to run SUT scripts.

  • Subject: Re: [qftestJUI] 'DeadlockTimeout' and threads created to run SUT scripts.
  • From: Gregor Schmid <Gregor.Schmid@?.de>
  • Date: 03 Nov 2006 08:40:48 +0100

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,

"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           
Tulpenstr. 41                                Tel: +49 8171 919870
DE-82538 Geretsried                          Fax: +49 8171 919876