I have a manager connector which mask alarms for services not on air. We are seeing some delays in the masking sometimes between 2-4 minutes to mask one single alarm for an element that can be found in about 3 services max.
This is the request
// mask alarm
var info = new SLNetMessages.SA
{
Sa = new[] { "-1", "Masking critical alarm for service " + serviceName + " since it is not currently on air." },
};
var message = new SLNetMessages.SetAlarmStateMessage
{
AlarmId = alarmId,
DataMinerID = dmaId,
HostingDataMinerID = dmaId,
ElementID = elementId,
Info = info,
State = Convert.ToInt32(AlarmState.Mask),
Value = String.Empty,
};protocol.Log($"QA{protocol.QActionID}|About to send SLNET|Right before sending {DateTime.Now}", LogType.Information, LogLevel.NoLogging);
var response = protocol.SLNet.SendSingleResponseMessage(message) as SLNetMessages.SetAlarmStateMessage;
The delay happens at the moment of sending the request. I have a log right before sending the request message and one after the response and we are getting the 2-4 minutes to mask this alarm.
Is there a way to follow the request or check why it takes so long?
Both from cube and using the client test tool the operation took less than a second, so for sure there is something wrong with the driver. I’m currently investigating after taking a look at the pending calls.
Thanks,
Issue was fixed by using a new protocol name and element. There was something external slowing down the original element.
It looks like this question has already been answered in the comments. To make it clear that this question no longer requires an answer, I have added this pro forma answer so that we can mark it as resolved.
Hi Geovanny, I would expect the same behavior when masking alarms directly from the Alarm Console. Do you also see the same delay there?