{"push_id":773098812,"size":1,"distinct_size":1,"ref":"refs/heads/master","head":"fd5c41d72083e09818e9f5b8ae53fbdd3428174e","before":"ca45f80fbb21649ed1124d549fab8110a3488e4b","commits":[{"sha":"fd5c41d72083e09818e9f5b8ae53fbdd3428174e","author":{"email":"044e56bde8a1cafe79dec83e58b6d6d16b60b4b0@hp.com","name":"Craig Bryant"},"message":"Threshold Engine is rejecting valid measurements\n\nIn the default case of a period being 60 and the evalation period being 60, the\nwindow was being alternately slid 0 slots and then 2 slots. This caused it to\nreject some recent measurements.\n\nTo illustrate what was happening, assume a SlidingWindow with a period of 60, and\na viewEndTimestamp of 60, and the AlarmDelay default of 30 seconds.  AlarmDelay is\nused to increase the likliehood a metric arrives before the window is evaluated.\nAlso assume the evaluation period is happening at 20 seconds after every minute.\n\nOn the first one, at time 20, the time is not past the viewEndTimeStamp so nothing\nhappens. On the second one, at time 80, the time is past the viewEndTimeStamp but\nthe window doesn't slide because the time has be > viewEndTimestamp + alarmDelay.\nAt time 140, time is > viewEndTimestamp + alarmDelay so the window is slid. However,\nsince the alarmDelay wasn't being accounted for in the number of slots to slide, it\nwas sliding it one too far. On the next period it wouldn't slide at all and then\nthe next one it would do two again.\n\nThis was fixed by accounting for alarmDelay when calculating the number of slots to\nslide\n\nChange-Id: I4fcfd41f2de515684b3d0054f9c46c925ee4807b","distinct":true,"url":"https://api.github.com/repos/stackforge/monasca-common/commits/fd5c41d72083e09818e9f5b8ae53fbdd3428174e"}]}