Hi Mark, Comments inline.
On Thu, Jan 6, 2011 at 8:15 AM, Mark Struberg <[email protected]> wrote: > Might have been a temporal problem locally since this special test performs > rather quick in our hudson: > > > https://hudson.apache.org/hudson/job/OpenJPA-trunk/370/org.apache.openjpa$openjpa-persistence-jdbc/testReport/ > Those tests don't take long on our CI server either, but I've seen the same problem with different tests. I've always assumed that there's GC or some other environmental issue that makes them take longer in Maven than they do independently. > The locking tests of corse are really slow in hudson too. > I'll confess that I usually skip the locking tests before committing (I don't think I'm alone here). One of the continuous integrations servers will catch locking bugs on the rare occasions that they crop up. > Might be worth moving all the expensive test into an own 'integration-test' > profile? > Otherwise developers will just take the shortcut and don't run the whole > build prior to a checkin because it takes so long ;) > I agree that's a real problem. We'll need to make sure that Hudson and any other CI servers hit all the tests. Part of the problem here is that the Hudson build errors have a poor signal to noise ratio. A large number of Hudson problems don't seem to be repeatable for me. But I digress. A build that takes over 1 hour is an impediment to new committers, and I'd be fine with moving the locking and other timing tests to an integration-test profile as long as Hudson executes them. How does this sound to others on the list? -mike > LieGrue, > strub > > --- On Thu, 1/6/11, Mark Struberg <[email protected]> wrote: > > > From: Mark Struberg <[email protected]> > > Subject: Tests take forever > > To: [email protected] > > Date: Thursday, January 6, 2011, 1:56 PM > > Hi! > > > > Anyone has an idea why some of our tests take almost > > forever when they run inside the build, but are very cheap > > if run standalone? > > > > My build currently takes ~ 1h 15minutes on a 4x3GHz and > > also not much longer on my notebook. This indicates that > > there is something 'foul' with them. Either they wait > > unnecessarily long or they do not scale (even when built > > with mvn -T4) > > > > An example: > > > > I got the following results for > > org.apache.openjpa.lib.conf.TestEquivalentConfiguration: > > testOldStylePersistenceUnitConfiguration > > 6.541 > > testNewStylePersistenceUnitConfiguration > > 206 > > > > testMixedStylePersistenceUnitConfiguration > > 223 > > > > testConflictStylePersistenceUnitConfiguration > > 18 > > testNewStyleSystemPropertyConfiguration > > 214 > > testOldStyleSystemPropertyConfiguration > > 223 > > > > testMixedStyleSystemPropertyConfiguration > > 256 > > > > testConflictStyleSystemPropertyConfiguration > > 16 > > testOldStyleRuntimePropertyConfiguration > > 249 > > testNewStyleRuntimePropertyConfiguration > > 231 > > > > testMixedStyleRuntimePropertyConfiguration > > 24 > > > > testConflictStyleRuntimePropertyConfiguration > > 18 > > > > makes 844 seconds in summary. > > > > But the same test passes in 4.034 seconds when I run this > > test in Idea (all 12 tests pass). > > > > I used the following VM settings: > > -Dopenjpa.Log=DefaultLevel=INFO > > -Dopenjpa.DynamicEnhancementAgent=false > > -Dopenjpa.ConnectionDriverName=org.apache.derby.jdbc.EmbeddedDriver > > > -Dopenjpa.ConnectionURL=jdbc:derby:target/database/openjpa-derby-database;create=true > > -Dopenjpa.ConnectionUserName= -Dopenjpa.ConnectionPassword= > > > > Is there anything I miss? > > > > Looks like we should pretty easily be able to slash down > > our build to 20 minutes or so... > > > > > > LieGrue, > > strub > > > > > > > > > > > >
