Notification Message Queue and Dispatch Settings

Definition

Before notification messages are delivered within a tag-based notification process or an asynchronous method call, they are placed in a queue. On the one hand, the queue decouples source system events from delivery of notification messages to the destination systems. So if there is a delay in delivery to a destination system, this doesn't block processing of further notification events at the source system. On the other hand, the queue makes sure that delivery retries can be started even if delivery attempts have failed.

For each agent instance, individual queues are used for sending notification messages. The queues are set up automatically as soon as you start an agent instance. The following queues are created:

Main queue
Queue for failed messages
Queue for expired messages
Queue for messages that are waiting to be bundled

The queues for an agent instance are removed when you delete the agent instance.

Procedure

In the Notification Message Queue and Dispatch Settings screen area on the Notification Processing tab, you can make the following settings:

Field	Description
Storage Method	Here you define how notification messages are to be stored in queues. You have the following options: In Memory Only Microsoft Message Queuing (MSMQ) File System For more information, see Storage Method.
Keep Messages in Memory	You can only select this option in conjunction with the storage method`file system`. If you choose this option, all notification messages from the main queue, the queue for failed messages, and the queue for messages for bundling are kept in memory by PCo. Note If there is an average volume of more than two notification messages per second, these options can increase the throughput of the queues. However, we recommend that you do not use this option for large notification messages of 100 kB and more. For the storage methods In Memory Only and Microsoft Message Queuing (MSMQ), all notification messages are kept exclusively or additionally in the memory.
Resend Failed Messages Automatically	If you choose this option, the system tries automatically after five to six minutes to resend failed notification messages that have been moved to the corresponding queue. The system determines the number of dispatch threads used for the resending of failed messages dynamically so that timely processing of messages from the main queue is guaranteed. If you do not select this option, but you still want to resend failed notification messages, you have to manually select the Resend All function on the Message Failures tab for the agent instance.
Keep Expired Messages	If you select the checkbox, notification messages that have expired (see Notification: Message Delivery Tab) are moved into the Expired Messages queue. They can be displayed there for evaluation purposes. The Expired Messages queue grows continuously if you do not delete notification messages from time to time. If you do not select the checkbox, the notification messages are deleted automatically and immediately from all queues when they expire.
Process Notification Messages Exactly Once in Order	By selecting this checkbox, you can define at agent instance level that all notification messages are delivered individually and exactly in the order in which they were placed in the queue in accordance with the delivery type Exactly Once in Order. Note In this case, the delivery of the messages is sequential. The Max. Dispatch Threads field is not relevant to the delivery type Exactly Once in Order and so you cannot change it. This setting overwrites the Process Notification Messages Exactly Once in Order setting that you have set at notification level. For more information, see Processing Notification Messages Exactly Once in Order.
Keep Copies of Queued Notification Messages in Journal Queue	If you select this checkbox, a copy of each notification message is stored in the Journal Messages folder of the Microsoft Message Queuing component. This option is only available in the storage method Microsoft Message Queuing (MSMQ). Note The Journal Message Queue folder is located, for example, in Windows 7 under Control Panel Administrative Tools Computer Management Services and Applications Message Queuing System Queues Journal Messages. You should only use this setting in the test phase for testing and for tracking errors, otherwise the contents of the directory can become too large and can have an adverse effect on performance.
Make Queued Notification Messages Recoverable	If you select the checkbox, MSMQ stores the notification messages on the hard disk. The notification messages then remain in the queue even if Windows has to be restarted. If you do not select the checkbox, the notification messages are only saved in the working memory. This leads to a better performance. Irrespective of this checkbox, notification messages are kept in the queue if the agent instance has to be restarted. This option is only available in the storage method Microsoft Message Queuing (MSMQ).
Max. Queued Messages	This field specifies the maximum number of notification messages that are allowed to be in the message queue. This includes messages on the Queued Messages and Message Failures tabs. When the specified number of messages has accumulated, the connection to the source system is terminated and the agent instance gets the status Error. You can enter `values up to 1,750,000,000`. The default value is 1000. At 80% of the value, the system issues a warning of the event type Critical in the message log. If you start the agent instance again when the maximum number of messages has already been exceeded, the upper limit is increased temporarily to 120% of the value so that you can resolve the situation when the agent instance is running. If you keep notification messages in the memory, choose a value here that is large enough so that no memory problems can occur during the runtime of the agent instance. For more information about estimating the memory requirements of message queues, see the Performance and Sizing Guide on the PCo product page.
Max. Dispatch Threads	This field specifies the maximum number of threads per processor core that are to be used for the asynchronous, parallel sending of notifications. The limits of this field are a minimum of 1 thread and a maximum of 250 threads per processor core. Therefore, you are effectively configuring a maximum number of parallel threads that results from the number of processor cores multiplied by the value specified in this field. The default value is 5. Example You enter a field value of `5`. Your PCo computer has eight processor cores. You thereby configure a maximum number of parallel threads of 8 x 5 threads = 40 threads. Caution At the runtime of the agent instance, the system only provides a limited number of possible parallel threads. The parallel threads are also used by other PCo processes, such as session handling for OPC UA functions. Therefore, you should not use the maximum value of 250 for the dispatch threads. Moreover, the possible message throughput of the destination systems used determines the number of dispatch threads that can be used with meaningful effect. For example, a connection to a Web server using a universal Web service destination system only provides a limited number of open HTTP connections. A large number of dispatch threads used that have a relatively small number of usable HTTP connections, can lead to a system load that is too high and can lead to long waiting times when agent instances are stopped. When the agent instance is started, a warning message appears in the agent log if the actual number of the maximum number of parallel threads you configured exceeds 60% of the threads provided by the system. The Max. Dispatch Threads field is not relevant to the delivery type Exactly Once in Order and so you cannot change it. In the case of the delivery type Exactly Once in Order, delivery is always synchronous and sequential.