Mailing list - Entries of 2006


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

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


  • Subject: [qftestJUI] 'DeadlockTimeout' and threads created to run SUT scripts.
  • From: "Adrian Chamberlain" <Adrian.Chamberlain@?.com>
  • Date: Wed, 1 Nov 2006 20:02:51 +0000

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

Attachment: common.qft
Description: Binary data

Attachment: MV38TestAutomation.qrz
Description: Binary data


Videos Downloads Documentation Buy Free Trial