Bug 534257 (RHQ-1070)
| Summary: | consider taking actions when agent goes away safely | ||
|---|---|---|---|
| Product: | [Other] RHQ Project | Reporter: | Joseph Marques <jmarques> |
| Component: | Agent | Assignee: | Nobody <nobody> |
| Status: | NEW --- | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | unspecified | Keywords: | FutureFeature, Improvement |
| Target Milestone: | --- | ||
| 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: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Joseph Marques
2008-11-06 18:08:00 UTC
This bug was previously known as http://jira.rhq-project.org/browse/RHQ-1070 mass add of key word FutureFeature to help track Joseph, what are your current thoughts on this? 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). |