[ https://issues.apache.org/jira/browse/SOLR-13376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16812880#comment-16812880 ]
Hoss Man commented on SOLR-13376: --------------------------------- {quote}This cleaning of leftover markers in OverseerTriggerThread was added early on when we added this functionality, and it may not be necessary anymore - there's InactiveMarkersPlanAction that runs periodically to remove stale markers. {quote} If this test doesn't reflect reality, and it's expected that {{InactiveMarkersPlanAction}} is what will clean up the markers, then the test needs fixed – because right now it (like many other auto-scalling tests) goes out of it's way to disable the {{.scheduled_maintenance}} trigger. For the record, this is the *exact* question I asked you about when you first resolved SOLR-13072 (but initially left this test marked AwaitsFix), but you never replied .. you just re-enabled the test (w/o any modifications to it) and re-resolved this issue... https://issues.apache.org/jira/browse/SOLR-13072?focusedCommentId=16732499&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16732499 Also: AFAICT there is *nothing* in the ref-guide that mentions the {{.scheduled_maintenance}} trigger, or any of it's (default) actions ({{inactive_shard_plan}}, {{inactive_markers_plan}}, {{execute_plan}}) or what they due, or why they (may) be important for cleaning up things like the nodeLost/nodeAdded markers. that seems like a problematic omission? > Multi-node race condition to create/remove nodeLost markers > ----------------------------------------------------------- > > Key: SOLR-13376 > URL: https://issues.apache.org/jira/browse/SOLR-13376 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Reporter: Hoss Man > Assignee: Andrzej Bialecki > Priority: Major > > NodeMarkersRegistrationTest.testNodeMarkersRegistration is frequently failing > on jenkins builds in the same spot, with a similar looking logs. > Although i haven't been able to reproduce these failures locally, I am fairly > confident that the problem is a race condition bug that exists between > when/how a new Overseer will process & clean up "nodeLost" marker's in ZK, > with how other nodes may (mistakenly) re-create those markers in their > liveNodes listener. -- This message was sent by Atlassian JIRA (v7.6.3#76005) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org