[ https://issues.apache.org/jira/browse/LUCENE-3429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dawid Weiss updated LUCENE-3429: -------------------------------- Attachment: LUCENE-3429.patch Updated slightly to avoid calling reportAdditionalFailureInfo before an actual timeout is hit. > improve build system when tests hang > ------------------------------------ > > Key: LUCENE-3429 > URL: https://issues.apache.org/jira/browse/LUCENE-3429 > Project: Lucene - Java > Issue Type: Test > Reporter: Robert Muir > Fix For: 3.5, 4.0 > > Attachments: LUCENE-3429.patch, LUCENE-3429.patch > > > Currently, if tests hang in hudson it can go hung for days until we manually > kill it. > The problem is that when a hang happens its probably serious, what we want to > do (I think), is: > # time out the build. > # ensure we have enough debugging information to hopefully fix any hang. > So I think the ideal solution would be: > # add a sysprop "-D" that LuceneTestCase respects, it could default to no > timeout at all (some value like zero). > # when a timeout is set, LuceneTestCase spawns an additional timer thread for > the test class? method? > # if the timeout is exceeded, LuceneTestCase dumps all thread/stack > information, random seed information to hopefully reproduce the hang, and > fails the test. > # nightly builds would pass some reasonable -D for each test. > separately, I think we should have an "ant-level" timeout for the whole > build, in case it goes completely crazy (e.g. jvm completely hangs or > something else), just as an additional safety. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org