openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Albert Lee <allee8...@gmail.com>
Subject Re: Junit tests taking longer to run on trunk?
Date Fri, 08 May 2009 02:45:41 GMT
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.

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