[
https://issues.apache.org/jira/browse/LUCENE-3429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13102301#comment-13102301
]
Robert Muir commented on LUCENE-3429:
-------------------------------------
I'm gonna play with the ant junit task timeout first, just to see if we can do
anything with it as a quick hack.
I suspect the problem will be that we won't get enough debugging information
via this mechanism (random seed, stacktraces).
> 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
>
>
> 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
