lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF subversion and git services (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SOLR-13118) Redesign integration tests for nodeAdded/nodeLost trigger state restoration
Date Tue, 08 Jan 2019 17:47:00 GMT

    [ https://issues.apache.org/jira/browse/SOLR-13118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16737332#comment-16737332
] 

ASF subversion and git services commented on SOLR-13118:
--------------------------------------------------------

Commit 612a1d029f69c268761306891c80e405341979e7 in lucene-solr's branch refs/heads/branch_7x
from Chris M. Hostetter
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=612a1d0 ]

SOLR-13118: Fix various nodeAdded/nodeLost trigger (integration) tests related to restoriung
state

This includes some cleanup and refactoring of unrelated test methods in the same classes to
use new helper methods

(cherry picked from commit 5a513fab8345cd0397435e7ce830268cd3763651)

Conflicts:
	solr/core/src/test/org/apache/solr/cloud/autoscaling/sim/SimSolrCloudTestCase.java


> Redesign integration tests for nodeAdded/nodeLost trigger state restoration
> ---------------------------------------------------------------------------
>
>                 Key: SOLR-13118
>                 URL: https://issues.apache.org/jira/browse/SOLR-13118
>             Project: Solr
>          Issue Type: Sub-task
>      Security Level: Public(Default Security Level. Issues are Public) 
>            Reporter: Hoss Man
>            Assignee: Hoss Man
>            Priority: Major
>         Attachments: SOLR-13118.patch
>
>
> The (integration) tests related to autoscaling nodeAdd/nodeLost trigger's and restoring
their state are problematic for a lot of reasons.
> Beyond some silly implementation mistakes, a fundemental timing/concurrency issue is
that (as designed) the tests have no way to ensure that "after" creating a nodeAdded/nodeLost
situation, they can wait for the (first instance of) the trigger to run() and detect the situation
(recording it in the trigger's internal state) so that the test can subsequently "update"
the trigger, forcing a new instance to restore the old state and then execute the trigger
actions.  This can result i na lot of flaky-ness if the triggers don't run when "expected"



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message