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
