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 Thu, 07 May 2009 20:35:54 GMT
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