hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From N Keywal <nkey...@gmail.com>
Subject Re: FW: Speeding up tests
Date Tue, 18 Oct 2011 19:36:30 GMT

I've identified a few sleep/wait related stuff, at the end it should cut the
start/stop time in half. I am waiting a little to see if it can be
generalized or not and I will publish them.

There are also possible improvements in the test themselves, small bug fixes
stuff, but it should buy a few minutes as well.

If I do things in a pure & clean way, that's gonna create a big big bunch of
very very small JIRAs. Is that ok, or do you prefer medium sized ones?

Then I will have a look at the profiler results. Who knows :-)

The next task could be defining the strategy for the split. I tend to
believe that we can categorize the tests between:
- core unit tests: with a contract: should be run before submitting a patch,
should not take too long, should not be flaky, should cover most of HBase
- long running tests: long or flaky, not on the core of HBase, or testing
specific cases (like timeout)

However, a failure of a test should break the central build, whatever the

I have not made my mind at all, just that this seems an easy way to make


On Tue, Oct 18, 2011 at 2:49 PM, N Keywal <nkeywal@gmail.com> wrote:

> Yes, putting then in a different phase. Actually , it could be done by
> renaming them, as surefire allows to launch a set of tests selected by a
> pattern (not tested :-).
> Tests like replication could fall into this approach, as it takes a lot of
> time, depends on the underlying cluster, and should not be impacted by most
> of the changes in HBase.
> Nicolas
> On Tue, Oct 18, 2011 at 1:15 PM, Stack <stack@duboce.net> wrote:
>> On Mon, Oct 17, 2011 at 8:20 PM, N Keywal <nkeywal@gmail.com> wrote:
>> > I was also thinking about splitting the test 'as they are' between the
>> long
>> > running ones & and the others, without changing them.
>> How you thinking of splitting them Nicolas?  You mean put them into a
>> separate phase or name them differently?
>> Good stuff,
>> St.Ack

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message