> On 24 maj 2016, at 09:06, serguei.spit...@oracle.com wrote: > > On 5/24/16 00:01, serguei.spit...@oracle.com > <mailto:serguei.spit...@oracle.com> wrote: >> On 5/23/16 23:35, Staffan Larsen wrote: >>> >>>> On 23 maj 2016, at 23:39, >>>> <mailto:serguei.spit...@oracle.com>serguei.spit...@oracle.com >>>> <mailto:serguei.spit...@oracle.com> wrote: >>>> >>>> Staffan, >>>> >>>> I do not see any issues, the fix looks good to me. >>> >>> Thanks! >>> >>>> One question though. >>>> >>>> Where does the TESTTIMEOUTFACTOR environment variable come from? >>>> I do not see it used anywhere in the jtreg tests. >>> >>> It is set by jtreg. See: >>> http://openjdk.java.net/jtreg/tag-spec.html#testvars >>> <http://openjdk.java.net/jtreg/tag-spec.html#testvars> >> Ok, I see. >> It looks like it was not used in the jtreg tests. >> But maybe my grep was not consistent. > > Probably, it is used in the property form: " test.timeout.factor”.
Yes, in Java tests it is used as the property. But in shell tests you have to use the environment variable. > > > Thanks, > Serguei > >> >> Thanks, >> Serguei >> >>> >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> On 5/23/16 02:17, Staffan Larsen wrote: >>>>> This is my second attempt at fixing this timeout by taking the jtreg >>>>> timeout factor into account in the tests. The first fix [1] looked at the >>>>> wrong environment variable, and also would have caused the test to run >>>>> unnecessarily slow since it set sleep_seconds to a higher value instead >>>>> of changing the timeout. >>>>> >>>>> In this version I have tried to fix these problems. I now look at the env >>>>> variable TESTTIMEOUTFACTOR which will contain the jtreg timeout factor in >>>>> floating point notation. Since it is easier to work with integers in >>>>> shell scripts, I truncate this value using and awk expression. I then use >>>>> this value to set up time limits in the two places where we have them. To >>>>> simplify the code in the cmd() function, I no longer print out stack >>>>> traces after half the timeLimit, only when the limit has expired. I think >>>>> this is reasonable. >>>>> >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8157555 >>>>> <https://bugs.openjdk.java.net/browse/JDK-8157555>webrev: >>>>> http://cr.openjdk.java.net/~sla/8157555/webrev.00/ >>>>> <http://cr.openjdk.java.net/%7Esla/8157555/webrev.00/> >>>>> >>>>> Thanks, >>>>> /Staffan >>>>> >>>>> [1] http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/5a553039e9fc >>>>> <http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/5a553039e9fc> >>> >> >
