This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 534257 - (RHQ-1070) consider taking actions when agent goes away safely
consider taking actions when agent goes away safely
Status: NEW
Product: RHQ Project
Classification: Other
Component: Agent (Show other bugs)
unspecified
All All
medium Severity medium (vote)
: ---
: ---
Assigned To: RHQ Project Maintainer
http://jira.rhq-project.org/browse/RH...
: FutureFeature, Improvement
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-11-06 13:08 EST by Joseph Marques
Modified: 2015-02-01 18:29 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Joseph Marques 2008-11-06 13:08:00 EST
when agent goes away we could do...

1) remove the agent from its connected server in the model? (so that the list agents / list servers HA admin pages show that the agent is down / not connected to anyone)
2) clear alerts caches? (since we always reload cache data upon agentConnect message, it would be possible to purge data ahead of time so that when the agent reconnects it only needs to perform a load)
Comment 1 Red Hat Bugzilla 2009-11-10 15:23:16 EST
This bug was previously known as http://jira.rhq-project.org/browse/RHQ-1070
Comment 2 wes hayutin 2010-02-16 12:09:32 EST
mass add of key word FutureFeature to help track
Comment 3 Corey Welton 2010-08-18 11:15:17 EDT
Joseph, what are your current thoughts on this?
Comment 4 Joseph Marques 2010-08-18 12:38:48 EDT
1) remove the agent from its connected server

yes, i still think it would be valuable to show users an up-to-date list of which agents are connected to which servers (as opposed to lazily updating the list).  however, this is not critical to any business functionality, it's just a matter of how stale/fresh (depending on which way you look at it) the information on the HA section of the admin pages are.

2) clear/purge alerts caches

there's no reason this needs to be performed as an agent is disconnecting from some server.  this can be a ejb3-timer job that wakes up (perhaps once every few minutes) and asks "which caches are loaded where i'm not currently managing that agent?" and then purge that data from memory.  as it stands right now, we have no mechanism for purging stale / out-of-date caches; therefore, over time, as different agents connect to each server that server's memory footprint will continue to grow.  granted, the footprint will reach a max when every cache in the system is loaded, but that was the point of partitioning the caches on an agent-by-agent basis to begin with, to allow each server to load (1/N)th of the alert cache data, where N is the number of known agents in the system.

-----

so we can probably close this BZ out corey, but we should open another one to capture (2).

Note You need to log in before you can comment on or make changes to this bug.