You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@trafficcontrol.apache.org by "ASF GitHub Bot (JIRA)" <ji...@apache.org> on 2017/08/06 05:00:12 UTC

[jira] [Commented] (TC-166) lastConfigCheck stat should be updated if CrConfigs have a different checksum but the same timestamp

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

ASF GitHub Bot commented on TC-166:
-----------------------------------

Github user asfgit commented on the issue:

    https://github.com/apache/incubator-trafficcontrol/pull/312
  
    Can one of the admins verify this patch?


> 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)