This is even better than I hoped for.
+1 to make the change. I already approved the PR.
On Fri, Dec 15, 2017 at 7:50 AM, Jens Deppe wrote:
> Using forkEvery=1, my distributedTest run took 3h5m which is maybe 10
> minutes slower than the random sampling I did of other tests and
> distributedTest
Using forkEvery=1, my distributedTest run took 3h5m which is maybe 10
minutes slower than the random sampling I did of other tests and
distributedTestCore took 2h35m which is on par with others.
I'd say that it's worth switching to forkEvery=1 as it will most likely
provide more consistency for te
Are the AcceptanceTests currently set to fork after every one? It might be
apples to oranges, but we could try to look at the cost difference there.
On Thu, Dec 14, 2017 at 4:24 PM, Kirk Lund wrote:
> Thanks Jens! Let us know if you end up running dunit in parallel with
> forkevery 1 or if it's
Thanks Jens! Let us know if you end up running dunit in parallel with
forkevery 1 or if it's completely serial (one at a time). I think parallel
with docker with forkevery 1 is going to give us the best results but I'm
sure you already know that since you're the docker king.
This change would elim
I'll do that.
On Thu, Dec 14, 2017 at 2:02 PM, Kirk Lund wrote:
> Someone needs to try it out. If there are any build-engineer types working
> on geode, then my suggestion is for them to try this change and report the
> timing difference.
>
> On Tue, Dec 12, 2017 at 2:22 PM, Alexander Murmann
>
Someone needs to try it out. If there are any build-engineer types working
on geode, then my suggestion is for them to try this change and report the
timing difference.
On Tue, Dec 12, 2017 at 2:22 PM, Alexander Murmann
wrote:
> Do we have a rough idea how forking every time would impact how lon
Do we have a rough idea how forking every time would impact how long tests
run?
On Tue, Dec 12, 2017 at 1:39 PM, Kirk Lund wrote:
> We should just change to fork every 1 instead of 30. Wasting time trying to
> debug statics is well... it's a waste of time. We should be focused on
> other things.
We should just change to fork every 1 instead of 30. Wasting time trying to
debug statics is well... it's a waste of time. We should be focused on
other things.
On Mon, Dec 11, 2017 at 9:05 PM, Jinmei Liao wrote:
> It doesn't call as much static methods as JUnit4DistributedTestCase.
> tearDownVM
It doesn't call as much static methods as JUnit4DistributedTestCase.tearDownVM,
see MemberStarterRule.after().
On Mon, Dec 11, 2017 at 4:36 PM, Dan Smith wrote:
> I don't think we are trying to reuse the distributed system - it gets
> disconnected after each test. See JUnit4DistributedTestCase.
I don't think we are trying to reuse the distributed system - it gets
disconnected after each test. See JUnit4DistributedTestCase.tearDownVM.
Are the new junit rules also cleaning things up?
-Dan
On Mon, Dec 11, 2017 at 4:16 PM, Kirk Lund wrote:
> Is there a reason we can't change Distributed
Is there a reason we can't change DistributedTestCase and subclasses to use
TemporaryFolder for all artifacts?
We could also disconnectAllFromDS in @AfterClass (or even @After) to get
things a bit more separate between dunit test classes.
Running dunit tests in parallel is much more important tha
One other thing you can do is look for the below line in the logs of your
failure. These are the tests that ran in the same JVM as your tests. This
won't help if your tests are getting messed up by disk artifacts or port
issues, but if it is some JVM state left by a previous test it would be in
thi
12 matches
Mail list logo
