brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sjcorbett <>
Subject [GitHub] incubator-brooklyn pull request: Republish request count sensors o...
Date Tue, 15 Dec 2015 16:17:24 GMT
GitHub user sjcorbett reopened a pull request:

    Republish request count sensors on poll failure

    Entities that use `org.apache.brooklyn.entity.webapp.WebAppServiceMetrics#REQUEST_COUNT`
are configured to republish the existing sensor value when a poll fails.
    The webapp entities (for Tomcat, JBoss, etc.) publish a request count sensor. `WebAppServiceMethods#connectWebAppServerPolicies(EntityLocal)`
is used by `JavaWebAppSoftwareProcess` (among others) to enrich the sensor into values for
    The clustered varieties of these entities (`DynamicWebAppCluster` and co.) enrich the
enriched values into cluster-wide aggregates.
    Enrichers are only updated when a value for the source sensor (request count) is published.
    If an entity's process fails then the poll for the request count sensor fails and no value
is published. As such, no values for the enriched sensors are published either and their values
must be considered incorrect. This then means that policies act on stale data rather than
the true state of the system.
    The change in this pull request configures the handful of entities that use the `REQUEST_COUNT`
sensor to republish the current value when a poll fails. Whether this is an appropriate thing
to do depends on whether you think a sensor's value represents a communique that Brooklyn
has learned something of the recent history of the system being monitored or that it represents
something that was true in the past. (I generally assume the latter since there is no notion
of timeliness when calling `sensors().get(key)`.)
    An alternative approach would be to adjust the aggregating enrichers to indicate that
entities whose status is not `RUNNING` should not be considered. The current design of the
aggregating enrichers does not make this as straightforward as the changes in this PR.
    Another would be to change `RollingTimeWindowMeanEnricher` to decay values outwith the
sensor event framework.
    I think this change is sufficient for the near future - it is much better than the status
quo - and that long term we should choose one of the alternatives (and also that I'm probably
overthinking this).

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

    $ git pull feature/republish-sensor-on-failure

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

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

    This closes #1109
commit 110d277924231939d48c36ccc4e4a10e84bfb7d5
Author: Sam Corbett <>
Date:   2015-12-14T16:28:35Z

    Polls for REQUEST_COUNT are configured to republish current val on error

commit 1b7b5a831605ce734ed804ac416703542a24a8c8
Author: Sam Corbett <>
Date:   2015-12-15T15:17:30Z



If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at or file a JIRA ticket
with INFRA.

View raw message