Bug 534257 (RHQ-1070)

Summary: consider taking actions when agent goes away safely
Product: [Other] RHQ Project Reporter: Joseph Marques <jmarques>
Component: AgentAssignee: RHQ Project Maintainer <rhq-maint>
Status: NEW --- QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: cwelton, hbrock
Target Milestone: ---Keywords: FutureFeature, Improvement
Target Release: ---   
Hardware: All   
OS: All   
URL: http://jira.rhq-project.org/browse/RHQ-1070
Whiteboard:
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:
Cloudforms Team: ---

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).