[
https://issues.apache.org/jira/browse/SOLR-11455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16197836#comment-16197836
]
Hoss Man commented on SOLR-11455:
---------------------------------
One possibility would be to make this test use a subclass of DUH2 that called
special methods on our MockEventListener when the {{UpdateHandler.commit(...)}}
method is called -- prior to calling {{super.commit(...)}} this could be used
to add timestamps to new {{BlockingQueue<Long> preSoft}} and
{{BlockingQueue<Long> preHard}} which could be checked with timing expectations
equal to the existing checks on the existing soft/hard queues, and new more
relaxed checks could be used to ensure that these commits do in fact eventually
finish (and trigger the normal EventListener methods)
> change SoftAutoCommitTest to check when events *start* -- not when they finish
> ------------------------------------------------------------------------------
>
> Key: SOLR-11455
> URL: https://issues.apache.org/jira/browse/SOLR-11455
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Hoss Man
> Attachments: SoftAutoCommitTest.jenkins.1398.txt
>
>
> 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.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
