[ 
https://issues.apache.org/jira/browse/LUCENE-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Muir updated LUCENE-2819:
--------------------------------

    Attachment: LUCENE-2819.patch

here's an updated patch, I think its much better.
The core tests are passing but still need to do contrib/solr.

Some problems i found, were having to 'actually close' the executorservices 
because ParallelMultiShredder doesnt wait for the shutdown to actually happen 
in its close().

Also the TimeLimitingCollector creates a new thread...statically! This just 
seems really evil.

I don't think tests should be creating threads and not cleaning up after 
themselves!

You might also ask why even bother killing the the threads if we will fail 
anyway? 
True we will already fail the test in this case, but this is just to try to
prevent the fails from being attributed to other test cases (the original 
problem here).


> LuceneTestCase's check for uncaught exceptions in threads causes collateral 
> damage?
> -----------------------------------------------------------------------------------
>
>                 Key: LUCENE-2819
>                 URL: https://issues.apache.org/jira/browse/LUCENE-2819
>             Project: Lucene - Java
>          Issue Type: Bug
>          Components: Tests
>            Reporter: Michael McCandless
>             Fix For: 3.1, 4.0
>
>         Attachments: LUCENE-2819.patch, LUCENE-2819.patch, LUCENE-2819.patch
>
>
> Eg see these failures:
>     https://hudson.apache.org/hudson/job/Lucene-3.x/214/
> Multiple test methods failed in TestIndexWriterOnDiskFull, but, I think only 
> 1 test had a real failure but somehow our "thread hit exc" tracking 
> incorrectly blames the other 3 cases?
> I'm not sure about this but it seems like something like that is going on...
> So, one problem is that LuceneTestCase.tearDown fails on any thread excs, but 
> if CMS had also hit a failure, then fails to clear CMS's thread failures.  I 
> think we should just remove CMS's thread failure tracking?  (It's static so 
> it can definitely bleed across tests).  Ie, just rely on LuceneTestCase's 
> tracking.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to