[
https://issues.apache.org/jira/browse/SOLR-11454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16197797#comment-16197797
]
Hoss Man commented on SOLR-11454:
---------------------------------
Here's an example of a jenkins failure (the full logs are no longer
available)...
https://builds.apache.org/job/Lucene-Solr-Tests-7.x/163/
{noformat}
FAILED:
org.apache.solr.update.SoftAutoCommitTest.testSoftAndHardCommitMaxTimeMixedAdds
Error Message:
hard529 was before searcher529: 6264322578200422 !<= 6264322016290268
Stack Trace:
java.lang.AssertionError: hard529 was before searcher529: 6264322578200422 !<=
6264322016290268
at
__randomizedtesting.SeedInfo.seed([995B4A163C40F912:C88FB3968D33C9B5]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at
org.apache.solr.update.SoftAutoCommitTest.testSoftAndHardCommitMaxTimeMixedAdds(SoftAutoCommitTest.java:230)
{noformat}
The intent here is to "verify" that the searcher was open because of the soft
commit -- not the hard commit. But there is no garuntee that a newSearcher
event triggered by the (auto)SoftCommit will finish before a subsequent hard
commit.
we should remove this (type of) check and instead either:
* wait for an extended period after the hard commit to assert there isn't a
second newSearcher
* add a varient of these test methods where hardAutoCommit is disabled to
ensure the searcher we eventually get is in fact because of the (auto)softCommit
** it would probably be pretty easy to parameterize the softCommitWaitMillis
and hardCommitWaitMillis in methods, so a variant could use
hardCommitWaitMillis=-1, and then do the hardCommit assertions conditionally if
and only if 0 < hardCommitWaitMillis
> relax newSearcher based time checks in SoftAutoCommitTest
> ---------------------------------------------------------
>
> Key: SOLR-11454
> URL: https://issues.apache.org/jira/browse/SOLR-11454
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Hoss Man
>
> The point of SoftAutoCommitTest is to ensure that auto-commits fire when
> expected.
> The timing based checks on those autocommits are a semi-neccessary evil to
> ensure that the test doesn't get false positives due to some other commits.
> The test also sanity checks that auto-commits result in newSearcher events
> if/when they should -- but these also (currently) have timing checks ot
> ensure that they happen "fast enough" ... this seems unneccessary (given the
> purpose of hte test) and broken (there's no guarantee/expectation how fast a
> searcher will open, even though the test assumes it will be a number relative
> to the autocommit setting.
> we should relax these assertions, and just ensure that the searcher
> *eventually* opens in a non-absurd amount of time, not fail if it isn't some
> specific math function relative to other events.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
