Done: HBASE-6655 I was thinking about a hard option: changing the fork timeout on build with the profile "runAllTests". Today is 15 minutes, at the beginning I would make it around 10 minutes, but with a progressive target of 5 minutes or so. This way, whatever takes too long will be VERY visible. When running a single test, it would be longer, allowing the user to debug or monitor as much as he wants...
On Fri, Aug 24, 2012 at 5:27 PM, Stack <[email protected]> wrote: > On Fri, Aug 24, 2012 at 6:54 AM, N Keywal <[email protected]> wrote: >> Hello, >> >> Running org.apache.hadoop.hbase.thrift.TestThriftServerCmdLine >> Tests run: 32, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 733.972 sec >> >> That's 12 minutes, not far from the current timeout for a single test >> (900 seconds). >> Is there anyone working on this or adding new tests there? >> As you know, if the test takes more time because there are new tests >> in it, it makes sense to break it in smaller pieces to get some >> parallelization. >> >> I've seen as well these ones: >> Running >> org.apache.hadoop.hbase.backup.example.TestZooKeeperTableArchiveClient >> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 284.153 sec >> >> Running org.apache.hadoop.hbase.io.encoding.TestChangingEncoding >> Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 299.748 sec >> >> I had a look at this last one, hopefully it will be reduced by 100s >> after HBASE-6654. >> >> Still, there is a lot of tests around the 3+ minutes execution time. >> It's better to stick to less than 1 minute as much as we can... If >> even worth checking this area during the code review I would say. >> > > Good point N. I like idea of checking test length as part of review. > > The above tests are mostly new I believe. We should have done better > job looking out for long-running tests. I'd say file an issue on the > 12minuter. That should be cut way down or just moved out to be an > out-of-bound Integration test. > > St.Ack
