[
https://issues.apache.org/jira/browse/TC-166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16125664#comment-16125664
]
ASF GitHub Bot commented on TC-166:
-----------------------------------
Github user asfgit commented on the issue:
https://github.com/apache/incubator-trafficcontrol/pull/312
Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/incubator-trafficcontrol-traffic_ops-test-PR/18/
> lastConfigCheck stat should be updated if CrConfigs have a different checksum
> but the same timestamp
> ----------------------------------------------------------------------------------------------------
>
> Key: TC-166
> URL: https://issues.apache.org/jira/browse/TC-166
> Project: Traffic Control
> Issue Type: Improvement
> Components: Traffic Router
> Affects Versions: 2.0.0
> Reporter: David Neuman
> Priority: Minor
> Labels: crconfig
>
> When Traffic Router checks for a new CrConfig it first checks to see if the
> CrConfig returned from Traffic Monitor has the same checksum as it's current
> version, if it doesn't then Traffic Router attempts to process it. During
> processing, if the new CrConfig has the same timestamp as the current
> CrConfig, Traffic Router logs and info message and returns false. A warning
> is then logged saying CrConfig has been rejected. This is ok, however, the
> lastConfigCheck stat is not updated. Since the CrConfigs are the same, the
> lastConfigCheck stat should be updated.
> This is basically an edge case that we came across because we are running
> javaTM and goTM in parallel. The lastConfigCheck stat was only being updated
> once every other poll, which cause our alarms to go off.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)