openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Donald Woods <dwo...@apache.org>
Subject Re: Junit tests taking longer to run on trunk?
Date Mon, 11 May 2009 14:59:06 GMT
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 <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
>>>>>>
>>>>>>
> 
> 

Mime
View raw message