Thanks for taking a look.
The changes in Rev773149 last Friday reduced the lockmgr runtime to
about 19-20 mins for me, so an improvement of about 5 mins, but still
seems like way too much time spent on unit tests for one piece of the
overall spec...
-Donald
Albert Lee wrote:
Donald,
I shall take a look tomorrow and see what can be done to shorten the
duration.
On Thu, May 7, 2009 at 8:54 PM, Donald Woods <[email protected]> wrote:
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
