https://github.com/OpenNMS/opennms/pull/1447

Excellent!

I've created . I'll add more details later.

Sounds reasonable to me.

I vote for keeping this issue only for implement the persistence of the state to disk, and create another enhancement issue for dynamically reload the engines when the configuration is changed.

That way, I can create a PR for this one right away.

I've created a new branch based on foundation-2017 called jira/NMS-9143-foundation-2017. The current changes are based on the original branch jira/NMS-9143 plus some additional changes.

Currently, it can manage the persistence to disk of the state when OpenNMS shutdown, and restore the state when OpenNMS starts, if there are no timer threads involved and persist-state="true" exist on the configuration for the engine in question.

The branch still requires some work prior create a PR.

It seems like implementing the hot-reload of the configuration is not easy based on how the correlator is initialized, and might require hard code changes (i.e. an important refactoring), which is the main reason why I've decided to exclude foundation-2016 from this solution.

I'm still trying to figure out what could be the best way to do this, based on the potential changes a user can made:

• Update an existing engine (apply changes on a existing directory inside /opt/opennms/etc/drools-endine.d/)

• Add a new engine (i.e. add new directory on /opt/opennms/etc/drools-endine.d/), which means register a new CorrelationEngine instance.

• Remove an engine (i.e. delete a directory from /opt/opennms/etc/drools-endine.d/), which means de-register and remove an existing CorrelationEngine instance.