Hi Mike, I am OK with moving/disabling locking tests and these four by default. Locking tests do not issue massive amounts of SQL so are not noticeably hit by OPENJPA-1876 issue and are slow by nature. It is not needed for this move/disabling to wait for OPENJPA-1876 resolution.
I just wanted to prevent anybody from moving/disabling a test which is slow because of OPENJPA-1876 and not by nature. Regards, Milosz > I agree with you about the tests identified in OPENJPA-1876. > > Would you be more comfortable if we moved or disabled the locking tests by > default? The locking tests take roughly 50% of the time to execute. > > The other tests I wanted to move are the ones that fail intermittently : > TestClearableScheduler > TestDataCachePCDataGenerator > TestTimestampVersion > TestSJVMCache > > I didn't realize that so many of these overlapped with 1876 until now. It's > probably worth holding off until we figure out what's going on with DBCP > (based on your update to the JIRA). > > -mike > > On Fri, Jan 7, 2011 at 10:56 AM, Miłosz Tylenda <mtyle...@o2.pl> wrote: > > > -1 > > > > It is a good idea but I think the time is wrong. We have introduced JDBC > > test slowness into 2.1 and 2.2 - see OPENJPA-1876 [1] - which is partly > > responsible for the long build time. The slowness should be identified and > > got rid off. > > > > Only after that we should determine which tests are slow by nature and > > separate them. Otherwise we risk hiding a problem instead of resolving it. > > > > As for OPENJPA-1876 I spent some hours on it and am still spending when the > > time permits but without amazing results. I have recently determined that > > DELETE statements are suspiciously slow on Derby but did not have yet time > > to compare it with older branches and determine whether it is the cause. > > Maybe someone will have better luck. > > > > Cheers, > > Milosz > > > > [1] https://issues.apache.org/jira/browse/OPENJPA-1876 >
