<AWT Dev>  Review Request: 8177841 Some java/awt/Robot tests can be improved
semyon.sadetsky at oracle.com
Tue Apr 11 15:23:59 UTC 2017
On 04/10/2017 09:20 PM, Sergey Bylokhov wrote:
>> 10 апр. 2017 г., в 18:18, Semyon Sadetsky <semyon.sadetsky at oracle.com
>> <mailto:semyon.sadetsky at 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
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the awt-dev