GitHub user sjcorbett opened a pull request:
https://github.com/apache/incubator-brooklyn/pull/1109
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.
**Context**
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 `REQUESTS_PER_SECOND_LAST` and `REQUESTS_PER_SECOND_IN_WINDOW` sensors.
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 https://github.com/sjcorbett/incubator-brooklyn
feature/republish-sensor-on-failure
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/incubator-brooklyn/pull/1109.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 #1109
----
commit 110d277924231939d48c36ccc4e4a10e84bfb7d5
Author: Sam Corbett <[email protected]>
Date: 2015-12-14T16:28:35Z
Polls for REQUEST_COUNT are configured to republish current val on error
commit b4086998c676bcffa7195ef351694a9a185e61cf
Author: Sam Corbett <[email protected]>
Date: 2015-12-15T14:39:11Z
Tidy
----
---
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 [email protected] or file a JIRA ticket
with INFRA.
---
