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
