[
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
ok final patch.
We can't quite fail() yet (it just warns for now) but we should fix it to fail.
For the solr tests we only test this in afterClass, this is because many solr
tests legitimately
start up threads in beforeClass and shut them down in afterClass.
This means we cant prevent 'collateral damage' in these solr tests, but we can
for lucene.
still for the solr tests, we can prevent collateral damage across test classes,
and find resource leaks.
> 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,
> 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: [email protected]
For additional commands, e-mail: [email protected]
