-
Type:
Bug
-
Status: Resolved (View Workflow)
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 23.0.1, Meridian-2018.1.3
-
Fix Version/s: 23.0.2, Meridian-2018.1.4
-
Component/s: Alarms / Automations / Vacuumd
-
Security Level: Default (Default Security Scheme)
-
Labels:
-
Sprint:Horizon - November 28th 2018
If an alarm is created immediately after the synchronization process is started, then the alarm can be erroneously deleted from the ktable.
While the state will be eventually consistent (rectified on the next sync) these deletes can cause problems for other systems integrating with the topics. In the case of OCE, this problem manifested itself by creating duplicate situations.
The following log snippet from karaf.log shows this in in action:
2018-11-25T10:08:03,353 DEBUG org.opennms.features.kafka.producer:24.0.0.SNAPSHOT(229) [alarmd-Thread-2-of-4] org.opennms.features.kafka.producer.OpennmsKafkaProducer: Sending alarm with reduction key: uei.opennms.org/alarms/situation:3efb2ef7-b973-430f-891e-c763268c35cd ... 2018-11-25T10:08:05,751 DEBUG org.opennms.features.kafka.producer:24.0.0.SNAPSHOT(229) [AlarmLifecycleListenerManager] org.opennms.features.kafka.producer.datasync.KafkaAlarmDataSync: Performing alarm synchronization with ktable. 2018-11-25T10:08:05,757 DEBUG org.opennms.features.kafka.producer:24.0.0.SNAPSHOT(229) [AlarmLifecycleListenerManager] org.opennms.features.kafka.producer.OpennmsKafkaProducer: Deleting alarm with reduction key: uei.opennms.org/alarms/situation:3efb2ef7-b973-430f-891e-c763268c35cd