Re: integration tests

[Christopher <ct...@apache.org>]

That doesn't work well with plugins that aren't all thread safe, and
may have other side-effects. Feel free to try it, if you like, but I
think it's sufficient to focus on optimizing the unit tests and
integration tests, because that's where it really matters.

--
Christopher L Tubbs II
http://gravatar.com/ctubbsii


On Fri, Sep 27, 2013 at 5:53 PM, Mike Drob <md...@mdrob.com> wrote:
> Maven already provides a -T option for multithreaded runs, and can even
> take a core multiplied factor. It would be nice to integrate with that in
> some way
> That's much better. It took me a few iterations to get down to an
> appropriate number of threads where it wouldn't fail, but being able to do
> it in 20 minutes blows 1+ hours out of the water
>
>
> On Fri, Sep 27, 2013 at 2:55 PM, Eric Newton <er...@gmail.com> wrote:
>
>> I've stabilized the integration tests. They run in a slow virtual machine,
>> and they run on my desktop.  You can use multiple forks to run the tests
>> more quickly:
>>
>>  $ mvn clean verify -Pnative -Daccumulo.it.forkCount=12
>>
>> That takes ~15 minutes.  My desktop has 8 cores and 30G of RAM.
>>
>> Please take the time to run the integration tests, and please open tickets
>> if you find them failing.
>>
>> I'm not going to turn these tests on for our Jenkin's build because they
>> will still timeout.
>>
>> -Eric
>>

Re: integration tests

[Michael Berman <mb...@sqrrl.com>]

It actually doesn't seem to work for me.  It doesn't break anything, but it
appears that nothing changes.  I'm a little concerned that I'm doing
something wrong, since neither switch seems to have any effect.  I'm still
getting one VM per test, and it's still running accumulo.it.forkCount
simultaneous threads, not accumulo.it.forkCount * [my core count].

If we assume that we have a separate VM per test class, and we don't care
about sharing MACs among SimpleMacIT subclasses, it makes ACCUMULO-1599 a
bit easier, since it also seems like the shutdown hook we're using for
cleanup doesn't get fired reliably from tests run from maven.  If we know
we're not trying to share resources among classes, we can just clean up in
an @AfterClass.

Think I should proceed with that assumption?  If we want to enable cluster
sharing in the future, we probably should use pre-integration-test and
post-integration-test, rather than trying to do it from within junit anyway.


On Mon, Oct 7, 2013 at 11:17 AM, Eric Newton <er...@gmail.com> wrote:

> If a couple people try it and it works for them, then sure!
>
> Does it work for you?
>
> -Eric
>
>
> On Mon, Oct 7, 2013 at 11:09 AM, Michael Berman <mb...@sqrrl.com> wrote:
> > This is awesome; thanks Eric!
> >
> > Should we set perCoreThreadCount for failsafe so people can take
> advantage
> > of the parallel speedup without having to remember to set
> accumulo.it.forkCount
> > manually?  If we set it to something relatively small, it shouldn't break
> > things on slow VMs, but would still benefit devs with beefier machines.
> >
> > Also, any reason not to set reuseForks?  Running from an IDE always
> reuses
> > the VM, and seems to work just fine.  This would also let us keep
> recycling
> > the same static minicluster between testclasses, which is no longer
> > happening in maven (although still happens in eclipse).
> >
> >
> > On Sun, Oct 6, 2013 at 12:25 AM, Christopher <ct...@apache.org>
> wrote:
> >
> >> That doesn't work well with plugins that aren't all thread safe, and
> >> may have other side-effects. Feel free to try it, if you like, but I
> >> think it's sufficient to focus on optimizing the unit tests and
> >> integration tests, because that's where it really matters.
> >>
> >> --
> >> Christopher L Tubbs II
> >> http://gravatar.com/ctubbsii
> >>
> >>
> >> On Fri, Sep 27, 2013 at 5:53 PM, Mike Drob <md...@mdrob.com> wrote:
> >> > Maven already provides a -T option for multithreaded runs, and can
> even
> >> > take a core multiplied factor. It would be nice to integrate with
> that in
> >> > some way
> >> > That's much better. It took me a few iterations to get down to an
> >> > appropriate number of threads where it wouldn't fail, but being able
> to
> >> do
> >> > it in 20 minutes blows 1+ hours out of the water
> >> >
> >> >
> >> > On Fri, Sep 27, 2013 at 2:55 PM, Eric Newton <er...@gmail.com>
> >> wrote:
> >> >
> >> >> I've stabilized the integration tests. They run in a slow virtual
> >> machine,
> >> >> and they run on my desktop.  You can use multiple forks to run the
> tests
> >> >> more quickly:
> >> >>
> >> >>  $ mvn clean verify -Pnative -Daccumulo.it.forkCount=12
> >> >>
> >> >> That takes ~15 minutes.  My desktop has 8 cores and 30G of RAM.
> >> >>
> >> >> Please take the time to run the integration tests, and please open
> >> tickets
> >> >> if you find them failing.
> >> >>
> >> >> I'm not going to turn these tests on for our Jenkin's build because
> they
> >> >> will still timeout.
> >> >>
> >> >> -Eric
> >> >>
> >>
>

Re: integration tests

[Eric Newton <er...@gmail.com>]

If a couple people try it and it works for them, then sure!

Does it work for you?

-Eric


On Mon, Oct 7, 2013 at 11:09 AM, Michael Berman <mb...@sqrrl.com> wrote:
> This is awesome; thanks Eric!
>
> Should we set perCoreThreadCount for failsafe so people can take advantage
> of the parallel speedup without having to remember to set accumulo.it.forkCount
> manually?  If we set it to something relatively small, it shouldn't break
> things on slow VMs, but would still benefit devs with beefier machines.
>
> Also, any reason not to set reuseForks?  Running from an IDE always reuses
> the VM, and seems to work just fine.  This would also let us keep recycling
> the same static minicluster between testclasses, which is no longer
> happening in maven (although still happens in eclipse).
>
>
> On Sun, Oct 6, 2013 at 12:25 AM, Christopher <ct...@apache.org> wrote:
>
>> That doesn't work well with plugins that aren't all thread safe, and
>> may have other side-effects. Feel free to try it, if you like, but I
>> think it's sufficient to focus on optimizing the unit tests and
>> integration tests, because that's where it really matters.
>>
>> --
>> Christopher L Tubbs II
>> http://gravatar.com/ctubbsii
>>
>>
>> On Fri, Sep 27, 2013 at 5:53 PM, Mike Drob <md...@mdrob.com> wrote:
>> > Maven already provides a -T option for multithreaded runs, and can even
>> > take a core multiplied factor. It would be nice to integrate with that in
>> > some way
>> > That's much better. It took me a few iterations to get down to an
>> > appropriate number of threads where it wouldn't fail, but being able to
>> do
>> > it in 20 minutes blows 1+ hours out of the water
>> >
>> >
>> > On Fri, Sep 27, 2013 at 2:55 PM, Eric Newton <er...@gmail.com>
>> wrote:
>> >
>> >> I've stabilized the integration tests. They run in a slow virtual
>> machine,
>> >> and they run on my desktop.  You can use multiple forks to run the tests
>> >> more quickly:
>> >>
>> >>  $ mvn clean verify -Pnative -Daccumulo.it.forkCount=12
>> >>
>> >> That takes ~15 minutes.  My desktop has 8 cores and 30G of RAM.
>> >>
>> >> Please take the time to run the integration tests, and please open
>> tickets
>> >> if you find them failing.
>> >>
>> >> I'm not going to turn these tests on for our Jenkin's build because they
>> >> will still timeout.
>> >>
>> >> -Eric
>> >>
>>

Re: integration tests

[Michael Berman <mb...@sqrrl.com>]

This is awesome; thanks Eric!

Should we set perCoreThreadCount for failsafe so people can take advantage
of the parallel speedup without having to remember to set accumulo.it.forkCount
manually?  If we set it to something relatively small, it shouldn't break
things on slow VMs, but would still benefit devs with beefier machines.

Also, any reason not to set reuseForks?  Running from an IDE always reuses
the VM, and seems to work just fine.  This would also let us keep recycling
the same static minicluster between testclasses, which is no longer
happening in maven (although still happens in eclipse).


On Sun, Oct 6, 2013 at 12:25 AM, Christopher <ct...@apache.org> wrote:

> That doesn't work well with plugins that aren't all thread safe, and
> may have other side-effects. Feel free to try it, if you like, but I
> think it's sufficient to focus on optimizing the unit tests and
> integration tests, because that's where it really matters.
>
> --
> Christopher L Tubbs II
> http://gravatar.com/ctubbsii
>
>
> On Fri, Sep 27, 2013 at 5:53 PM, Mike Drob <md...@mdrob.com> wrote:
> > Maven already provides a -T option for multithreaded runs, and can even
> > take a core multiplied factor. It would be nice to integrate with that in
> > some way
> > That's much better. It took me a few iterations to get down to an
> > appropriate number of threads where it wouldn't fail, but being able to
> do
> > it in 20 minutes blows 1+ hours out of the water
> >
> >
> > On Fri, Sep 27, 2013 at 2:55 PM, Eric Newton <er...@gmail.com>
> wrote:
> >
> >> I've stabilized the integration tests. They run in a slow virtual
> machine,
> >> and they run on my desktop.  You can use multiple forks to run the tests
> >> more quickly:
> >>
> >>  $ mvn clean verify -Pnative -Daccumulo.it.forkCount=12
> >>
> >> That takes ~15 minutes.  My desktop has 8 cores and 30G of RAM.
> >>
> >> Please take the time to run the integration tests, and please open
> tickets
> >> if you find them failing.
> >>
> >> I'm not going to turn these tests on for our Jenkin's build because they
> >> will still timeout.
> >>
> >> -Eric
> >>
>