Notification Queuing

All notifications (synchronous callbacks and event notifications) originating from any of the EasyXXClient or EasyXXSubscriber objects are (by default) sent in a queued manner by a dedicated internal thread, improving resiliency against errors in custom code, and decreasing the possibility of deadlocks. When there is a sudden peak in the rate of incoming events, they can accumulate temporarily in the queue, allowing the processing to proceed smoothly.

This notification queuing can be turned on or off by the QueueNotifications property. Turning off the notification queuing is only advisable in very special circumstances. When the notification queuing is turned off, the callback and event handling is subject to much stricter rules with regard to performance, but also with regard to what the handlers are allowed to do. Most importantly, the handlers must not call any methods on the originating component, because doing so can cause deadlocks. This rule also applies to calls that may be inflicted by the SynchronizationContext on the component. For example, the common synchronization contexts based on Windows messages (for Windows Forms and WPF) can call other "posted" methods before the action that are instructed to do, causing unpredictable behavior and a possible deadlock too.

For the reasons described above, do not turn the notification queuing off unless you know very well what you are doing.

The capacity of the notification queue is given by the NotificationQueueCapacity property. The memory is not pre-allocated for the full maximum size, however, and therefore under normal circumstances, there is no penalty for using quite high queue capacities. The notification queue capacity should be large enough to be able to hold all incoming notification in case of a sudden "burst", before they are all processed (consumed) by your code.

For errors coming from subscriptions, OPC Data Client uses the same "channel" as for success notifications. For example, in case of the EasyUAClient Class, this means that the errors come through the DataChangeNotification Event or EventNotification Event, and the component treats each monitored item separately. Consequently, in case of an error that affects the whole connection to a particular server (or more servers), callbacks (and/or events) will be generated for every monitored item affected. This is by design. If you are subscribed to larger number of monitored items, this itself can create a "burst" that is way above the normal rate of events. Your code, and the size of the notification queue, need to be prepared for this scenario as well.

If the amount of notifications that needs to be held in the queue exceeds its capacity, a notification queue overflow occurs, and these notifications are lost. In addition, a LogEntry Event is generated on the EasyXXClient or EasyXXSubscriber, with corresponding message. If a notification is removed from a queue while it has overflown, the overflow status is cleared, and a different LogEntry Event is generated on the component ("overflow clearing"). The event contains overflow count, which is effectively the number of notifications that have been lost due to the queue overflow.

The idle time before the internal thread executing the queued notification is stopped is controlled by the NotificationQueueIdleTimeToSleep property. The thread is stopped as an optimization measure, to reduce the amount of system resources consumed. When new notification come, the thread is automatically started.