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

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

GitHub user dneuman64 opened a pull request:

    https://github.com/apache/incubator-trafficcontrol/pull/312

    [TC-166] Traffic Router now updates the lastConfigCheck stat if timestamps 
of …

    …CrConfigs match
    
    This fixes [TC-166](https://issues.apache.org/jira/browse/TC-166)

You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/dneuman64/incubator-trafficcontrol TC-166

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/incubator-trafficcontrol/pull/312.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #312
    
----
commit 6b05b17f0655f1cdccebb512a3538aeb609ea0c7
Author: Dave Neuman <[email protected]>
Date:   2017-02-26T21:38:16Z

    Traffic Router now updates the lastConfigCheck stat if timestamps of 
CrConfigs match

----


> 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
>
> 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.3.15#6346)

Reply via email to