Bug 534257 (RHQ-1070) - consider taking actions when agent goes away safely
Summary: consider taking actions when agent goes away safely
Keywords:
Status: NEW
Alias: RHQ-1070
Product: RHQ Project
Classification: Other
Component: Agent
Version: unspecified
Hardware: All
OS: All
medium
medium
Target Milestone: ---
: ---
Assignee: Nobody
QA Contact:
URL: http://jira.rhq-project.org/browse/RH...
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-11-06 18:08 UTC by Joseph Marques
Modified: 2024-03-04 13:35 UTC (History)
0 users

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed:
Embargoed:


Attachments (Terms of Use)

Description Joseph Marques 2008-11-06 18:08:00 UTC
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 20:23:16 UTC
This bug was previously known as http://jira.rhq-project.org/browse/RHQ-1070


Comment 2 wes hayutin 2010-02-16 17:09:32 UTC
mass add of key word FutureFeature to help track

Comment 3 Corey Welton 2010-08-18 15:15:17 UTC
Joseph, what are your current thoughts on this?

Comment 4 Joseph Marques 2010-08-18 16:38:48 UTC
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.