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 >
