[
https://issues.apache.org/jira/browse/LUCENE-8716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16784749#comment-16784749
]
Erick Erickson commented on LUCENE-8716:
----------------------------------------
[~hossman] The state of the shutdown call is in flux. The current state is that
it does _not_ call the log4j shutdown code. Well, actually it calls
StartupLoggingUtils.shutdown(), but all the code there is commented out. We
were focusing on lmax.disruptor issues which mysteriously disappeared when we
had any logger instantiated, which was done in SolrTestCaseJ4, so we were
testing just that.
And it doesn't seem to matter how much I beast this stuff, I can't get them to
fail locally, thus the noise.
Apparently just instantiating a logger will keep the lmax.disruptor problem
from happening, but not this one. Which answers the question "should we call
the shutdown code" with "yes".
So here's my proposal at this point. Let's re-enable the call to the logger
shutdown. It was always a weak solution that just declaring a logger worked. It
looks like the answer to "do we really need to call the shutdfown" is an
emphatic "yes".
[~dweiss] I'd say you should totally ignore this issue while we figure this out.
> 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: [email protected]
For additional commands, e-mail: [email protected]
