[ 
https://issues.apache.org/jira/browse/LUCENE-3429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13102458#comment-13102458
 ] 

Dawid Weiss commented on LUCENE-3429:
-------------------------------------

I wrote that snippet yesterday as a proof of concept - it is simple and I think 
does the job (you can control timeouts of all tests of a class, a single test's 
timeout time or, in case of Lucene, global timeouts on all tests simply by 
putting the rule in the superclass of all tests).

In fact, JUnit4 already has two built-in options for doing timeouts: a @Timeout 
rule much like mine (but not logging object's internal fields) and 
@Test(timeout=...). My implementation simple expands on this by adding a "live" 
dump of objects being tested (important in case of live fields) -- sending a 
signal (or ctrl-break combination on windows) will dump the spinning test's 
fields to the console.

I can prepare a patch, but it's actually trivial to just take the rule's code 
from github and paste in LuceneTestCase. Should work out of the box, perpahs 
with changes related to the fact that I used commons-lang for dumping the 
target object and we may simply restrict it to dumping the current seed.

> 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
>
>
> 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

Reply via email to