Log In
Home
04/14/2020
Offline
We are testing alarms and are scaling up the system to a large number of alarms. With numbers > 1000 or so, we are seeing that when we have the client issue the ConditionRefresh method, we are only getting 900 alarms back from the server, i.e., the client’s Notification event on the MonitoredItem is only getting called 900 times, even though it should be > 1000.
We are using the .NET Standard server and client libraries.
Any ideas as to what we might look for?
05/30/2017
Offline
Are you sure the Servers queues are not overflowing?
All servers have finite queues to prevent resource exhaustion.
Once you confirm all notifications are sent then you will need to investigate a .NET threading issue.
I suggest you process the notification messages manually (there is a different callback on the subscription object) instead of relying on the monitored item callback. You could quickly dump all the messages into a queue and process them on another thread.
04/14/2020
Offline
Randy Armstrong said
Are you sure the Servers queues are not overflowing?All servers have finite queues to prevent resource exhaustion.
Once you confirm all notifications are sent then you will need to investigate a .NET threading issue.
I suggest you process the notification messages manually (there is a different callback on the subscription object) instead of relying on the monitored item callback. You could quickly dump all the messages into a queue and process them on another thread.
Okay, I did confirm that we are hitting the maximum queue size and dropping some of the notification messages. We are hitting this code path:
// have to drop unsent messages if out of queue space.
int overflowCount = messages.Count – (int)m_maxMessageCount;
if (overflowCount > 0)
{…
}
So the way to handle this is to configure larger limits using these configuration properties I assume?
public int MaxMessageQueueSize
public int MaxNotificationQueueSize
public int MaxNotificationsPerPublish
1 Guest(s)
Usage Policy