Errata exists for this version of the document.

If the sample passes the filter criteria, a Notification is generated and queued for transfer by the Subscription. The size of the queue is defined when the MonitoredItem is created. When the queue is full and a new Notification is received, the Server either discards the oldest Notification and queues the new one, or it replaces the last value added to the queue with the new one. The MonitoredItem is configured for one of these discard policies when the MonitoredItem is created. If a Notification is discarded for a DataValue and the size of the queue is larger than one, then the Overflow bit (flag) in the InfoBits portion of the DataValue statusCode is set. If discardOldest is TRUE, the oldest value gets deleted from the queue and the next value in the queue gets the flag set. If discardOldest is FALSE, the last value added to the queue gets replaced with the new value. The new value gets the flag set to indicate the lost values in the next NotificationMessage. Figure 17 illustrates the queue overflow handling.

Figure 17 – Queue overflow handling

If the queue size is one, the queue becomes a buffer that always contains the newest Notification. In this case, if the sampling interval of the MonitoredItem is faster than the publishing interval of the Subscription, the MonitoredItem will be over sampling and the Client will always receive the most up-to-date value. The discard policy is ignored if the queue size is one.

On the other hand, the Client may want to subscribe to a continuous stream of Notifications without any gaps, but does not want them reported at the sampling interval. In this case, the MonitoredItem would be created with a queue size large enough to hold all Notifications generated between two consecutive publishing cycles. Then, at each publishing cycle, the Subscription would send all Notifications queued for the MonitoredItem to the Client. The Server shall return Notifications for any particular item in the same order they are in the queue.

The Server may be sampling at a faster rate than the sampling interval to support other Clients; the Client should only expect values at the negotiated sampling interval. The Server may deliver fewer values than dictated by the sampling interval, based on the filter and implementation constraints. If a DataChangeFilter is configured for a MonitoredItem, it is always applied to the newest value in the queue compared to the current sample.

If, for example, the AbsoluteDeadband in the DataChangeFilter is “10”, the queue could consist of values in the following order:

• 100
• 111
• 100
• 89
• 100

Queuing of data may result in unexpected behaviour when using a Deadband filter and the number of encountered changes is larger than the number of values that can be maintained. The new first value in the queue may not exceed the Deadband limit of the previous value sent to the Client.

The queue size is the maximum value supported by the Server when monitoring Events. In this case, the Server is responsible for the Event buffer. If Events are lost, an Event of the type EventQueueOverflowEventType is placed in the queue. This Event is generated when the first Event has to be discarded on a MonitoredItem subscribing for Events. It is put into the Queue of the MonitoredItem in addition to the size of the Queue defined for this MonitoredItem without discarding any other Event. If discardOldest is set to TRUE it is put at the beginning of the queue and is never discarded, otherwise at the end. An aggregating Server shall not pass on such an Event. It shall be handled like other connection error scenarios.