On 04/10/2017 09:20 PM, Sergey Bylokhov wrote:
10 апр. 2017 г., в 18:18, Semyon Sadetsky <semyon.sadet...@oracle.com
<mailto:semyon.sadet...@oracle.com>> написал(а):
On 04/10/2017 06:15 AM, Sergey Bylokhov wrote:
We already have a mechanism which kills the tests after timeout,
we also have a default timeout of 2 minutes.
I am not sure how to get dump of all threads from the catch block.
But shouldn't the time frame when a mouse click may come be
limited? Will it be correct when the click triggered after 2
minutes delay makes the test passed anyway?
If timeout will occur and the test still was not complete, then it
will be killed, all frames will be closed, the dump of all threads
will be generated. So the test cannot pass after timeout.
I meant when the listener is triggered right before the 2 minutes
timeout, for example in 1 minute 59 seconds. In the current logic
the test passes in this case and no dumps were generated for any
thread. But actually this means an issue because event shouldn't be
delayed for that amount of time or this event is not generated by
the test.
If the test will complete successfully before timeout then it will
validate the functionality which it was targeted for. The slowness
can be from the slow/embedded system, or if the system was
overloaded by some other tasks. If the test will fails on such
systems by the timeout then the user will be able to tweak it via
jtreg parameter.
Anyway 2 minutes seems a very unusual waiting time for the event at
any circumstances. Usually, in the client-libs tests after an action
is triggered, we wait for silence in all event queues plus a small
period of several hundreds milliseconds. Why in this particular test
such huge waiting is necessary?
Usually we wait in the test some amount of time in the common code
path, when the test is passed. This "small period of time" usually
tweaked for the slow systems, so we could get a situation when the
test is executed more than 2 minutes in the common case(when it is
passed). Because the «small period of time» is different between
common systems and slow/embeded systems. The approach in the current
test will work instantly on the fast systems, and will wait till
timeout on the slow systems. To summarize we already have timeout
handling in the jtreg and should not reinvent it per test.
We should keep the general approach. I've never seen fixes that require
2 minutes waiting for an event. 5 seconds waiting would be enough for
any platform and for the most heaviest toolkit actions (in the current
test you wait for a single mouse button click which is one of the
lightest).
I see a lot of disadvantages of the new event waiting approach you've
introduced. That infinite waiting relying on jtreg timeout may cause
unreasonable increase of test execution time. Also, I suppose that the
situation when mouse button event comes later than in 5 seconds on any
embedded system bears an investigation and the test should fail.
It is not a load testing but an usual UI testing and this means an issue
if UI doesn't react to mouse click for seconds (not even to mention the
minutes...). Imagine yourself as a user of such UI.
