[jira] [Updated] (SOLR-11454) relax newSearcher based time checks in SoftAutoCommitTest

["Hoss Man (JIRA)" <ji...@apache.org>]

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

Hoss Man updated SOLR-11454:
----------------------------
    Attachment: SoftAutoCommitTest.jenkins.178.txt

Here's another type of failure, full jenkins log attached as SoftAutoCommitTest.jenkins.178.txt

https://builds.apache.org/job/Lucene-Solr-Tests-7.x/178/
{noformat}
Error Message:
searcher529 wasn't soon enough after soft529: Took 1143ms, >= acceptable 300ms (fudge)

Stack Trace:
java.lang.AssertionError: searcher529 wasn't soon enough after soft529: Took 1143ms, >= acceptable 300ms (fudge)
        at __randomizedtesting.SeedInfo.seed([37A167B6A7C72C70:F0EDDF2BBC6FE1C0]:0)
        at org.junit.Assert.fail(Assert.java:93)
        at org.junit.Assert.assertTrue(Assert.java:43)
        at org.apache.solr.update.SoftAutoCommitTest.testSoftAndHardCommitMaxTimeDelete(SoftAutoCommitTest.java:366)
{noformat}

In this case we can see from the logs that the {{Opening \[Searcher@6f2d6505\[collection1] main]}} happend the _exact_ same millisecond that the soft commit started & ended -- but because the event listeners don't fire until the _end_ of the event, this assertion considers the newSearcher too slow (relative to how long the softCommit itself took)

we should remove this variable "fudge" and just assert that the searcher opened eventually.

> 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
>         Attachments: SoftAutoCommitTest.jenkins.178.txt
>
>
> 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org