You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ambari.apache.org by "Jonathan Hurley (JIRA)" <ji...@apache.org> on 2015/02/26 05:39:04 UTC

[jira] [Created] (AMBARI-9807) Store Configuration In Agent Memory For Alerts

Jonathan Hurley created AMBARI-9807:
---------------------------------------

             Summary: Store Configuration In Agent Memory For Alerts
                 Key: AMBARI-9807
                 URL: https://issues.apache.org/jira/browse/AMBARI-9807
             Project: Ambari
          Issue Type: Task
          Components: ambari-agent
    Affects Versions: 2.0.0
            Reporter: Jonathan Hurley
            Assignee: Jonathan Hurley
            Priority: Critical
             Fix For: 2.0.0


https://issues.apache.org/jira/browse/AMBARI-8885 fixes a problem where agents required a restart in order for the alert framework to pickup configuration changes.

Initially, alerts were designed so that they only received the parameters they requested. A single alert definition might only need a couple of values (such as hdfs-site/foo) as opposed to the entire configuration structure.

However, it seems like we're doing a lot of extra work to ensure that these values are kept current; alert definitions need to be rescheduled when a configuration changes so that its cached value can be updated.

It would be good to investigate (and implement if plausible) a way to store the entire configuration structure in memory and have it accessible to alerts (and any other part of the agent framework). This would allow us to:

- Remove the code that caches values in the alert jobs before they are schedule
- Remove the code the restarts jobs on configuration changes
- Have an up-to-date configuration structure that is easily accessible without the need to parse any files on-disk

The major concern would be that keeping such a large structure in memory could cause some kind of performance degradation or memory overhead that would be unacceptable. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)