Mailing List - Entries of 2015

List Icon
Mailing list Archive

2019 up to July 2022 | 2018 | 2017  |  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]

[QF-Test] Shouldn't "Wait for client to connect" check if the client is (still) running?

  • Subject: [QF-Test] Shouldn't "Wait for client to connect" check if the client is (still) running?
  • From: Michael Pruemm <eso@?.org>
  • Date: Fri, 17 Jul 2015 15:13:47 +0200
Hi all,

I just had the following interesting scenario: My tests start the
client, which immediately fails because the JVM cannot allocate
sufficient memory. Right after the "Start SUT client", I wait for the
client to connect. This fails of course after the timeout with a
"ClientNotConnectedException".

This is of course technically correct, since the client did not connect.

However, since the client failed to start immediately, it was not even
running when the "Wait for client to connect" started to execute. In
that case, I would expect a "NoSuchClientException".

The description for ClientNotConnectedException seems to back me up here:


It differs from a NoSuchClientException in that there is an active
process for that name but no RMI connection.


I just confirmed that behavior by creating a new "Wait for client to
connect" node with a time-out of 2s and a client name of "foo". When I
execute this, it leads to a ClientNotConnectedException instead of a
NoSuchClientException.


To work around this problem, I am using this:

+ Start SUT client: $(client), delay after 2000 -- client starts slowly
+ If "${qftest:client.exitcode.$(client)}" != ""
  + call qfs.utils.testrun.stop.stopTestRun
+ Try
  + Wait for client to connect
  + Catch ClientNotConnectedException
    + ... deal with it somehow ...

Is this the best approach?


Here a few more details about my setup: QFTest 4.0.5; the client is a
Java application that gets started via a shell script.

- Michael

We use "Matomo" cookies to anonymously evaluate your visit to our website. For this we need your consent, which is valid for twelve months. A revocation, so-called opt-out, is possible at any time on our privacy page.

accept
configuration
Cookie configuration

1. Functional cookies

We use functional cookies to ensure the basic functionality of the website.

2. Performance and statistic cookies

We use Matomo for analyzing and optimizing our website. Cookies permit an anonymous collection of information that help us offering you a clear and user-friendly visit of our web pages.

Confirm selection

Cookie details