You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Erick Erickson (JIRA)" <ji...@apache.org> on 2019/03/04 22:06:00 UTC
[jira] [Comment Edited] (LUCENE-8716) Test logging can bleed from
one suite to another, cause failures due to sysout limits
[ https://issues.apache.org/jira/browse/LUCENE-8716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16783823#comment-16783823 ]
Erick Erickson edited comment on LUCENE-8716 at 3/4/19 10:05 PM:
-----------------------------------------------------------------
[~hossman] This worries me since it might be related to switching to async logging by default, including the tests. It sure sounds in the same neighborhood at least. SOLR-12055 and SOLR-13268, especially since TestStressReorder is a Solr test.
Tests with async logging are having weird stuff bubble up out of the cracks, lmax.disruptor for instance. Kevin and I have some leads. One of the solutions is to subclass all the tests in Solr from SolrTestCaseJ4 rather than LuceneTestCase to insure that the proper logging shutdown happens. Which I'm experimenting with now, but don't feel very good about. I want to see if it's possible then discuss.
If the logging output is _always_ from TestStressReorder, we could put the shutdown for async logging specifically in that class as a test, I can help with that. I stress that this is only to see if this the underlying problem, not a robust solution.
Saying "well, our test framework doesn't like async logging, therefore we shouldn't do it" smells. AFAIK, this is a test-only problem, not a problem actually running Solr.
OTOH, changing about 150 test classes to derive from SolrTestCaseJ4 rather than LuceneTestCase smells too.
OTOOH, playing whack-a-mole with individual tests (or perhaps combinations of tests) smells too.
OTOOOH, saying "async logging should work, but we can't make our tests play nice with it, therefore use at your own risk" smells too.
[~krisden] WDYT about whether the async logging might be part of this?
All this assuming this failure is related to the async logging...
was (Author: erickerickson):
[~hossman] This worries me since it might be related to switching to async logging by default, including the tests. It sure sounds in the same neighborhood at least. SOLR-12055 and SOLR-13268, especially since TestStressReorder is a Solr test.
Tests with async logging are having weird stuff bubble up out of the cracks, lmax.disruptor for instance. Kevin and I have some leads. One of the solutions is to subclass all the tests in Solr from SolrTestCaseJ4 rather than LuceneTestCase to insure that the proper logging shutdown happens. Which I'm experimenting with now, but don't feel very good about. I want to see if it's possible then discuss.
If the logging output is _always_ from TestStressReorder, we could put the shutdown for async logging specifically in that class as a test, I can help with that. I stress that this is only to see if this the underlying problem, not a robust solution.
Saying "well, our test framework doesn't like async logging, therefore we shouldn't do it" smells. AFAIK, this is a test-only problem, not a problem actually running Solr.
OTOH, changing about 150 test classes to derive from SolrTestCaseJ4 rather than LuceneTestCase smells too.
OTOOH, playing whack-a-mole with individual tests (or perhaps combinations of tests) smells too.
OTOOOH, saying "async logging should work, but we can't make our tests play nice with it, therefore use at your own risk" smells too.
[~krisden] WDYT about whether the async logging might be part of this?
> Test logging can bleed from one suite to another, cause failures due to sysout limits
> -------------------------------------------------------------------------------------
>
> Key: LUCENE-8716
> URL: https://issues.apache.org/jira/browse/LUCENE-8716
> Project: Lucene - Core
> Issue Type: Test
> Reporter: Hoss Man
> Priority: Major
> Attachments: thetaphi_Lucene-Solr-master-Linux_23743.log.txt
>
>
> in solr land, {{HLLUtilTest}} is an incredibly tiny, simple, test that tests a utility method w/o using any other solr features or doing any logging - as such it extends {{LuceneTestCase}} directly, and doesn't use any of the typical solr test framework/plumbing or {{@SuppressSysoutChecks}}
> on a recent jenkins build, {{HLLUtilTest}} failed due to too much sysoutput -- all of which seems to have come from the previous test run on that JVM -- {{TestStressReorder}} -- suggesting that somehow the sysout from one test suite can bleed over into the next suite?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org