Move RTC over to Spring and Hibernate
Description
Acceptance / Success Criteria
Lucidchart Diagrams
Activity
Seth Leger February 18, 2015 at 1:18 PM
I've merged my branch where RTC is refactored to use Hibernate and JDBC calls to calculate the availability instead of using an in-memory record of outages that is updated based on incoming events. This rework will be included in OpenNMS 16.
I'm going to mark this bug as resolved. We can open new issues for using Camel+ActiveMQ for the messaging; the POST infrastructure is working fine for now and it accomplished the architectural goal of keeping heavyweight availability calculations outside of the UI rendering threads. Marking as fixed.
Seth Leger January 21, 2015 at 4:46 PM
I have refactored RTC into a Spring daemon and I replaced the in-memory state system with DAO and JDBC database calls that calculate the availability and category membership during every update to the UI. This work is in the feature-refactor-rtc-with-spring branch and will be merged for inclusion in OpenNMS 16.
We still need to investigate using Camel+ActiveMQ to transmit availability data to the UI or whether the availability calculations can be done inside a bean inside the UI instead of using the awkward POST infrastructure that is there now.
RTC currently uses a thread pool to periodically execute JDBC queries to calculate the 24h availability of each category. It needs to be refactored to use dependency injection for initialization, to move away from using JDBC, and to use a pluggable way to transmit the availability information to the UI and respond to configuration changes.
The preferred architecture for this would be to move RTC to DAO-based data access and use Camel+ActiveMQ for messaging between it and the web UI.