I agree. Moving other tests would take further investigation, maybe a separate JIRA for each group of tests.
-mike On Mon, Jan 10, 2011 at 9:49 AM, Miłosz Tylenda <[email protected]> wrote: > 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 <[email protected]> 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 > > >
