[ https://issues.apache.org/jira/browse/LUCENE-3429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13103982#comment-13103982 ]
Dawid Weiss commented on LUCENE-3429: ------------------------------------- Ehm. So... I figured out at least the reason for the fact the tests hang on mac/linux if the patch is applied. The reason is this in TestConcurrentMergeScheduler): {code} @Override public void eval(MockDirectoryWrapper dir) throws IOException { if (doFail && (Thread.currentThread().getName().equals("main") || Thread.currentThread().getName().equals("Main Thread"))) { {code} because we're spawning threads named differently this test never finishes (because this condition never occurs). Is this supposed to check if the code runs a test case? If so then I suggest a different way of checking this: create a field on LuceneTestCase with {code} volatile Thread current; {code} this would be set by the runner (or a rule, whatever) and then test cases could verify they are running inside a test case by comparing Thread.currentThread() == current. Sounds good? > 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