<AWT Dev> [9] Review Request: 8177841 Some java/awt/Robot tests can be improved

[Sergey Bylokhov]

> 10 апр. 2017 г., в 18:18, Semyon Sadetsky <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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170411/6e4a3d26/attachment.html>