You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by Donald Woods <dw...@apache.org> on 2009/05/07 21:59:55 UTC
Junit tests taking longer to run on trunk?
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
Re: Junit tests taking longer to run on trunk?
Posted by Michael Dick <mi...@gmail.com>.
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 <pp...@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 <dw...@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.
>
>
Re: Junit tests taking longer to run on trunk?
Posted by Pinaki Poddar <pp...@apache.org>.
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 <dw...@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.
Re: Junit tests taking longer to run on trunk?
Posted by Donald Woods <dw...@apache.org>.
Thanks for taking a look.
The changes in Rev773149 last Friday reduced the lockmgr runtime to
about 19-20 mins for me, so an improvement of about 5 mins, but still
seems like way too much time spent on unit tests for one piece of the
overall spec...
-Donald
Albert Lee 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 <dw...@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
>>>>>>
>>>>>>
>
>
Re: Junit tests taking longer to run on trunk?
Posted by Albert Lee <al...@gmail.com>.
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 <dw...@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.
Re: Junit tests taking longer to run on trunk?
Posted by Donald Woods <dw...@apache.org>.
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
>>>>
>>>
>>
>
Re: Junit tests taking longer to run on trunk?
Posted by Donald Woods <dw...@apache.org>.
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
>>>
>>
>
Re: Junit tests taking longer to run on trunk?
Posted by Donald Woods <dw...@apache.org>.
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
>>
>
Re: Junit tests taking longer to run on trunk?
Posted by Miłosz Tylenda <mt...@o2.pl>.
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
>