Red Hat Bugzilla – Bug 871873
Availability check change is not automatically picked up
Last modified: 2013-09-03 10:42:19 EDT
+++ This bug was initially created as a clone of JBoss ON Bug #869716 +++
Description of problem:
When Availability check is changed, for instance from enabled to disabled, this change is not picked up by the agent and availability is still checked and server status changed depending on it's real state.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Import JBoss instance;
2. Navigate to Monitor -> Schedule (for that server instance) and disable Availability check;
3. After some time (at least 2 minutes if Availability check was initially set to 1 minute), stop the JBoss instance;
4. Execute "avail --force" on the JON Agent command line;
5. Check the status of the JBoss server;
The status of the JBoss instance changes to DOWN in JON UI.
JBoss stays UP because it picks up the status of its parent resource (platform) as explained in .
The change in Availability check will be propagated after the agent is restarted with "--purgedata" option.
I can see that MeasurementManager.scheduleCollection() is doing the correct thing, but that is when we are setting the entire set of collection schedules. When updating in MeasurementManager.updateCollection() it does look like the avail metric is ignored. If it is in the set it should be updated.
The availability schedule is not in the set. So I have made a fix inspired by what is done in MeasurementManager.scheduleCollection().
Could you please review the modifications done in the specific branch ?
Caveat that because of the internal behavior of availability checking, the "real" schedule will always be a multiple of 30s (rate of the availability check executor thread).
UI schedule/Actual schedule
Merged into master 257e056
Remote branch bug/871873 deleted
Please ignore comment 3: the "real" interval can indeed be longer than the interval saved in UI, as availability scheduled is respected on best effort.
But the interval is not necessarily a multiple of 30s
Bulk closing of issues in old RHQ releases that are in production for a while now.
Please open a new issue when running into an issue.