openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Dick <michael.d.d...@gmail.com>
Subject Re: Junit tests taking longer to run on trunk?
Date Mon, 11 May 2009 17:29:46 GMT
This is one of the reasons I'd like to move over to jUnit 4.x. EMF
initialization / cleanup could be done in @BeforeClass / @AfterClass
methods. The catch is the using jUnit 4 uses around 4x the heap space. I'm
not sure whether this is a result of using jUnit 4 to run jUnit 3 tests, or
whether it would be the case if we converted the entire bucket though.

Making the EMF static in SingleEMFTC should have the same effect, but I
haven't had a chance to try it out..

-mike

On Mon, May 11, 2009 at 11:28 AM, Pinaki Poddar <ppoddar@apache.org> wrote:

>
> Hi,
>  One more way to speed up is to reduce initialization cost.
> SingleEMFTestCase does not really lives up to its name, meaning for a
> TestCase we are not using a single EMF but for each method EMF is getting
> initialized. That has a upfront cost in terms of schema definition. Most of
> the test cases, however, can work with a single EMF for all its individual
> testXXX() methods.
>
>
> allee8285 wrote:
> >
> > Donald,
> >
> > I shall take a look tomorrow and see what can be done to shorten the
> > duration.
> >
> >
> > On Thu, May 7, 2009 at 8:54 PM, Donald Woods <dwoods@apache.org> wrote:
> >
> >> Just ran a compile+test with loglevel=TRACE on openjpa-persistence-jdbc
> >> using Rev762563 on April 6 (which included the lockmgr additions on
> April
> >> 5)
> >> and it took 51 mins, so it looks like the lockmgr tests are the cause of
> >> the
> >> almost 100% increase in time to run the junit tests.....
> >>
> >> Albert, can we somehow reduce the scope of these tests?
> >>
> >>
> >> -Donald
> >>
> >>
> >>
> >> Donald Woods wrote:
> >>
> >>> Tried rebuilding Rev760056 from March 30 (after the OPENJPA-5 changes
> >>> for
> >>> JDK6) and it took 25 mins. for compile+test of openjpa-persistence-jdbc
> >>> with
> >>> loglevel=TRACE, so still looking....
> >>>
> >>> -Donald
> >>>
> >>>
> >>> Donald Woods wrote:
> >>>
> >>>> Yep, I'm stuck trying to add the derby.locks timeouts, as the lockmgr
> >>>> tests need a waitTimeout > 20 seconds (haven't determined exact number
> >>>> as
> >>>> the tests dynamically determine their wait time based on the speed of
> >>>> the
> >>>> system....)
> >>>>
> >>>> Just went back and looked at a trunk build I still had from March 24
> >>>> and
> >>>> the compile + test run for all the trunk modules took 27 mins. on my
> >>>> Mac,
> >>>> versus 51 mins. now....  :-(
> >>>>
> >>>>
> >>>> -Donald
> >>>>
> >>>>
> >>>> MiƂosz Tylenda wrote:
> >>>>
> >>>>> I have also noticed this. I don't think the metamodel and criteria
> >>>>> stuff
> >>>>> is the cause. I suspect we test a lot of method call permutations
and
> >>>>> the
> >>>>> tests are mainly waiting for deadlock or timeout. I am also in favor
> >>>>> of
> >>>>> trying to reduce the time. Maybe not all premutations are needed
or
> >>>>> query
> >>>>> timeouts may be set to some lower value.
> >>>>>
> >>>>> Greetings,
> >>>>> Milosz
> >>>>>
> >>>>>  Just noticed in the past week or so that the
> openjpa-persistence-jdbc
> >>>>>> bucket went from taking about 30 mins. to run for me under JDK5
on
> my
> >>>>>> Mac
> >>>>>> (Core 2 Duo @ 2.5GHz) to around 45 mins. now (and same results
on
> >>>>>> WinXP)....
> >>>>>>  Anyone else noticed this?
> >>>>>>
> >>>>>> So, I dug into the openjpa-persistence-jdbc results and noticed
that
> >>>>>> the lockmgr tests are taking about 26 mins. of that time to
run by
> >>>>>> just
> >>>>>> executing that subset of tests -
> >>>>>>    mvn -o test -Dtest=org.apache.openjpa.persistence.lockmgr.*
> >>>>>> -Dopenjpa.loglevel=TRACE
> >>>>>>
> >>>>>> Looking at the run times -
> >>>>>>
> org.apache.openjpa.persistence.lockmgr.TestMixedLockManagerRefreshPermutation
> >>>>>> takes 15 mins. to run
> >>>>>>
> org.apache.openjpa.persistence.lockmgr.TestMixedLockManagerLockPermutation
> >>>>>> takes 4.2 mins. to run
> >>>>>>
> org.apache.openjpa.persistence.lockmgr.TestMixedLockManagerFindPermutation
> >>>>>> takes 4.2 mins. to run
> >>>>>>
> >>>>>> Has there been any relevant changes introduced by the recent
> >>>>>> metamodel
> >>>>>> or criteria work that could have affected the tests like this?
> >>>>>>
> >>>>>> If not, is there anyway we can reduce the amount of time or
number
> of
> >>>>>> tests we run for lockmgr testing?  Seems that we have included
way
> >>>>>> too many
> >>>>>> tests (creates/deletes around 678 threads during the tests)
for a
> >>>>>> simple
> >>>>>> unit test goal and most of these could be moved to a SVT bucket....
> >>>>>>
> >>>>>>
> >>>>>> -Donald
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >
> >
> > --
> > Albert Lee.
> >
> >
>
>
> -----
> Pinaki Poddar                      http://ppoddar.blogspot.com/
>
> http://www.linkedin.com/in/pinakipoddar
> OpenJPA PMC Member/Committer
> JPA Expert Group Member
> --
> View this message in context:
> http://n2.nabble.com/Junit-tests-taking-longer-to-run-on-trunk--tp2836004p2863995.html
> Sent from the OpenJPA Developers mailing list archive at Nabble.com.
>
>

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