fd5c41d720
In the default case of a period being 60 and the evalation period being 60, the window was being alternately slid 0 slots and then 2 slots. This caused it to reject some recent measurements. To illustrate what was happening, assume a SlidingWindow with a period of 60, and a viewEndTimestamp of 60, and the AlarmDelay default of 30 seconds. AlarmDelay is used to increase the likliehood a metric arrives before the window is evaluated. Also assume the evaluation period is happening at 20 seconds after every minute. On the first one, at time 20, the time is not past the viewEndTimeStamp so nothing happens. On the second one, at time 80, the time is past the viewEndTimeStamp but the window doesn't slide because the time has be > viewEndTimestamp + alarmDelay. At time 140, time is > viewEndTimestamp + alarmDelay so the window is slid. However, since the alarmDelay wasn't being accounted for in the number of slots to slide, it was sliding it one too far. On the next period it wouldn't slide at all and then the next one it would do two again. This was fixed by accounting for alarmDelay when calculating the number of slots to slide Change-Id: I4fcfd41f2de515684b3d0054f9c46c925ee4807b
Overview
monasca-common is a collection of sub-projects containing reusable application and platform code for building monitoring related services.
Build Instructions
Download and do mvn install.
cd java
mvn clean install
There is a pom.xml in the base directory but that should only be used for the StackForge build. The issue is that currently StackForge's bare-precise system only has Maven 2 on it and at least one of the modules of monasca-common requires Maven 3.
In order to get around this problem, the pom.xml in the base directory uses the exec-maven-plugin to run the script run_maven.sh. This script checks if the version of mvn is Maven 3 and if it is not, it downloads Maven 3 and then uses it to run the build in the java directory.
In addition, the run_maven.sh script copies the jar files that get built from java/*/target directories to the target directory in the base project directory. This is because the StackForge "monasca-common-localrepo-upload" job uploads any jar files from that directory to http://tarballs.openstack.org/ci/monasca-common. Copying the jar files to that directory made it so there didn't have to be changes made to the "monasca-common-localrepo-upload" job. The build for monasca-thresh downloads the jars it depends on from that location on tarballs.openstack.org.
A change has been submitted to StackForge to switch to bare-trusty for this build in the hopes that those systems will have maven 3, but it is not known how long that change will take to be accepted.
Application Specific Sub-Projects
- monasca-common-model - Common domain and event models for monitoring services.
Platform Sub-Projects
- monasca-common-dropwizard - Utilities for building and testing dropwizard services.
- monasca-common-kafka - Various utilities for working with Kafka.
- monasca-common-persistence - Persistence related infrastructure and utilities.
- monasca-common-service - Simple service abstractions and utilities.
- monasca-common-streaming - Streaming related utilities.
- monasca-common-testing - A set of testing related dependencies.
- monasca-common-util - Various utilities such as for serialization, dependency injection, date and time, invocation retries, concurrency, etc.