[
https://issues.apache.org/jira/browse/HELIX-683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16414717#comment-16414717
]
Hudson commented on HELIX-683:
------------------------------
FAILURE: Integrated in Jenkins build helix #1424 (See
[https://builds.apache.org/job/helix/1424/])
[HELIX-683] clean monitoring cache upon helix controller enable (zhan849: rev
24f2610f69714e68e31dcb2581d790c699ec05a1)
* (edit)
helix-core/src/main/java/org/apache/helix/controller/stages/ClusterDataCache.java
* (add)
helix-core/src/test/java/org/apache/helix/integration/controller/TestControllerLeadershipChange.java
* (edit)
helix-core/src/main/java/org/apache/helix/controller/GenericHelixController.java
> Clean monitoring cache upon helix controller enable monitoring
> --------------------------------------------------------------
>
> Key: HELIX-683
> URL: https://issues.apache.org/jira/browse/HELIX-683
> Project: Apache Helix
> Issue Type: Bug
> Reporter: Hao Zhang
> Priority: Major
>
> We found a bug in reporting cluster status, partition masterless duration.
> The root cause is that the duration is calculated based on controller cache.
> And currently, this cache is not cleaned when leadership is changed. As a
> result, if controller A start a mastership handoff but was interrupted once,
> the start time will be kept in cache until next mastership handoff on the
> same partition happens. Then the later handoff duration will be calculated
> based on the stale start time. This could be super large.
> To fix it, we might consider clean cache when leadership changed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
