REST API subscription for alarms repeats alarms when SS is restarted
search cancel

REST API subscription for alarms repeats alarms when SS is restarted

book

Article ID: 131768

calendar_today

Updated On:

Products

CA Spectrum

Issue/Introduction

After configuring a REST API to pull alarms with a subscription, when the SpectroSERVER process is restarted, the API will flood the subscription with all the alarms active on the SS, even though they had previously come through and been processed prior to the SpectroSERVER restart.

Environment

Release: 20.2.x
Component: SPCAPP - Spectrum Applications

Cause

REST APIs are stateless in design so they do not maintain information about previous interactions with the client.  When the SpectroSERVER is restarted, existing alarms are removed from the cache and persistent alarms are added back into the cache on the OneClick console. Then, when the REST GET is run on the subscription id, it displays them as a new alarm even though the alarm id is the same.

 As a result when using the REST subscription e.g. for alarms, we will see duplicated alarms when the SpectroSERVER fails over to the fault tolerant secondary SpectroSERVER.  This is how REST as a stateless API is supposed to work.  Thus any client that consumes data from a REST API is responsible for removing such duplicates which are a known issue of stateless APIs.  

This is why we recommend to use SANM for 3rd party integrations as the SANM application is stateful and so does not show from this behavior. 

 

Resolution

This is functioning as designed. The recommendation is to keep a log of the active alarm id's and compare the added alarm id's with this log to determine if the alarm should be processed further.