Details
-
Improvement
-
Status: Open
-
Major
-
Resolution: Unresolved
-
None
-
None
-
None
-
None
Description
AFAICT, most "slow machine" related (jenkins) failures in SoftAutoCommitTest seem to be exacerbated by the fact that the SolrEventListener model fires an effent when the action (softCommit, hardCommit, newSearcher) finishes successfully – w/o paying any attention to when it starts.
We should consider taking a more white/grey box approach to checking both the start & finish of these events – and moving our autoCommit timing expectations to the "start" of the commits, with much more relaxed (ie: many seconds) checks that the event finished successfully.
Attachments
Attachments
Issue Links
- relates to
-
SOLR-11053 Improve SoftAutoCommitTest to the point that we can delete AutoCommitTest and HardAutoCommitTest
- Closed
some of the comments in SOLR-11454 are an example of where tracking the (newSearcher) event finish results in a failure but tracking the even start would show it happened very quickly.
The attached jenkins log (SoftAutoCommitTest.jenkins.1398.txt) is another example...
https://builds.apache.org/job/Lucene-Solr-NightlyTests-master/1398/
After some rapid fire adds, the test does a loop looking for an expected# of commits based on the relative pre/post timestamp of the adds (ie: at least 1 softCommit, maybemore more if the total time to add the docs exceeded the autoCommitTime) .. but in this vase it fails because it didn't dedect a softCommit finish in the expected wait time.
But according to the logs, the autoSoftCommit started exactly when expected (508ms after the first doc was added, or 8ms after the autoSoftCommitMillis=500 said it should) ...
...it just didn't finish as quickly as the monitor polling expected it to.