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
