List Icon
Mailing list Archive

2019 up to July 2022 | 20182017  |  2016  2015 2014 | 2013

The mailing list has been closed since July 2022, but continues to serve as an archive of information about QF-Test.
But if you want to stay informed about news about QF-Test, you can simply
Subscribe to Newsletter  

To get up-to-date information about each release - including minor releases - you can
subscribe to the RSS feed or follow us on social media.
Alternatively, QF-Test also provides release information itself.

Another source of information is our blog, where there are current articles on general topics, on the company QFS and also various "how-tos"
subscribe to blog


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

Re: [QF-Test] QF-Test playback lockup when performing actions on specific components


  • Subject: Re: [QF-Test] QF-Test playback lockup when performing actions on specific components
  • From: Gregor Schmid <Gregor.Schmid@?.de>
  • Date: Sat, 13 Sep 2014 20:28:42 +0200

Hello Ron,

that's an interesting case. QF-Test itself is not deadlocked and
according to your description neither is the SUT. Such a case can
happen, for example, when you trigger something from an SUT script
which triggers a nested event loop, e.g. to display a modal dialog.
The SUT is still live, but control doesn't return to the script until
the dialog is closed.

There are various workarounds available, depending on the actual
situation. If after the deadlock timeout the test can continue as if
nothing had happened, a common solution is:

+ Server script 1
+ Try
  + Action that triggers the deadlock
  + Catch DeadlockTimeoutException
  + Finally
    + Server script 2

In server script 1, set the deadlock detection timeout to a reasonable
small value, e.g. 3 seconds:

rc.setOption(Options.OPT_PLAY_TIMEOUT_DEADLOCK, 3)

In server script 2, reset the option

rc.unsetOption(Options.OPT_PLAY_TIMEOUT_DEADLOCK)

If that is not good enough, please send a run-log showing the
exception to our support. It would also be helpful if you could send a
full thread dump taken at the time while QF-Test is waiting for the
SUT. You can take it either with QF-Test via the >>Clients<< menu,
provided that output from the SUT is shown in QF-Test, or with a tool
like jvisualvm that comes with the JDK (not with a JRE though).

Best regards,
    Greg

Ron Britzius <britziusr@?.net> writes:

> Hello,
>
> The issue we are experiencing is that when QF-Test attempts to perform an action on specific
> components (there are 2 known examples in our project) it will occasionally completely lock up and
> effectively end that test-run.  When it occurs, the play arrow remains highlighted and the pause
> button does not change (as if it is still actively playing). It will remain this way until the
> deadlock detection timeout elapses and the SUT lockup message appears even though the SUT is
> perfectly fine. 
>
> If the playback stop button is pressed while QF-Test is locked up like this, the action it became
> stuck on will execute. If the dialog or window that contains the component it became locked up on
> is manually closed during lock-up the playback will move to the next step.
>
> Both components seem to be search-related. One is a search bar and the other is a dropdown combo
> that populates its combo list based on the text you enter in the combo text box.
>
> Thank you,
> Ron Britzius 
>
> _______________________________________________
> qftest-list mailing list
> qftest-list@?.de
> http://www.qfs.de/mailman/listinfo/qftest-list

--
Gregor Schmid

E: gregor.schmid@?.de
T: +49 (0)8171 38648-11
F: +49 (0)8171 38648-16

Quality First Software GmbH | www.qfs.de
Tulpenstr. 41 | 82538 Geretsried | Germany
GF Gregor Schmid, Karlheinz Kellerer
HRB München 140833