<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <p><br>
    </p>
    <br>
    <div class="moz-cite-prefix">On 04/10/2017 09:20 PM, Sergey Bylokhov
      wrote:<br>
    </div>
    <blockquote
      cite="mid:0A82DDBC-7810-456D-B74A-1AFE8CE21D4C@oracle.com"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
      <br class="">
      <div>
        <blockquote type="cite" class="">
          <div class="">10 апр. 2017 г., в 18:18, Semyon Sadetsky <<a
              moz-do-not-send="true"
              href="mailto:semyon.sadetsky@oracle.com" class="">semyon.sadetsky@oracle.com</a>>
            написал(а):</div>
          <br class="Apple-interchange-newline">
          <div class="">
            <meta content="text/html; charset=utf-8"
              http-equiv="Content-Type" class="">
            <div bgcolor="#FFFFFF" text="#000000" class="">
              <p class="">On 04/10/2017 06:15 AM, Sergey Bylokhov wrote:<br
                  class="">
              </p>
              <blockquote
                cite="mid:6FC79B5C-CC21-4B20-8F3E-CB97AD7DC005@oracle.com"
                type="cite" class="">
                <meta http-equiv="Content-Type" content="text/html;
                  charset=utf-8" class="">
                <div class="">
                  <blockquote type="cite" class="">
                    <div class="">
                      <div bgcolor="#FFFFFF" text="#000000" class="">
                        <blockquote
                          cite="mid:05895DD4-DE43-4BF2-998B-372EBD94FDBF@oracle.com"
                          type="cite" class="">
                          <div class="">
                            <blockquote type="cite" class="">
                              <div class="">
                                <div bgcolor="#FFFFFF" text="#000000"
                                  class="">
                                  <blockquote
                                    cite="mid:1D6419F2-4F6E-42ED-AB49-735D62031359@oracle.com"
                                    type="cite" class="">
                                    <div class="">
                                      <div class=""><br class="">
                                      </div>
                                      <div class="">We already have a
                                        mechanism which kills the tests
                                        after timeout, we also have a
                                        default timeout of 2 minutes.</div>
                                      <div class="">I am not sure how to
                                        get dump of all threads from the
                                        catch block.</div>
                                    </div>
                                  </blockquote>
                                  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?<br class="">
                                </div>
                              </div>
                            </blockquote>
                            <div class=""><br class="">
                            </div>
                            <div class="">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.</div>
                          </div>
                        </blockquote>
                        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. <br class="">
                      </div>
                    </div>
                  </blockquote>
                  <div class=""><br class="">
                  </div>
                  <div class="">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.</div>
                </div>
              </blockquote>
              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?<br class="">
            </div>
          </div>
        </blockquote>
        <br class="">
      </div>
      <div>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.</div>
    </blockquote>
    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).  <br>
    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. <br>
    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.<br>
  </body>
</html>