Notification-Specific Settings
The notification-specific settings enable you to configure certain scheduling aspects of polling notifications on an individual basis.
Two new fields appear on the Polling Notification Schedule page: Coordination Mode and Max Process Time. These fields become editable when you add your Integration Server to a cluster.
The
Coordination Mode field controls the coordination of the notification schedules across the cluster. Depending on the value you assigned to the
runtimeModeLimit setting (see
Adapter-Specific Settings), the adapter user can select some combination of the following values in the
Coordination Mode field as follows:
This runtimeModeLimit value... | Displays these values in the Coordination Mode field... |
disable | disable |
standby | disable and standby |
distribute | disable, standby, and distribute |
The
Max Process Time field enables other notifications to determine whether a currently executing notification should be considered to be “dead”. If a notification executes a scheduled run and it fails to complete before the
Max Process Time, then another notification instance will consider it dead; this other notification will assume control and execute a scheduled run. The default value is equal to the value in the watt.art.clusteredPollingNotification.keepAliveExpireTimeout setting in the server.cnf file.
If the Max Process Time setting is not high enough, you may encounter a situation in which a notification is executing normally, but another notification assumes it is “dead”. When the original notification completes, it will recognize that it was prematurely considered “dead”. In this case, the system logs an Illegal Overlap exception with message ID [ART.116.3715]. If this exception occurs, increase your Max Process Time setting.
When setting the value of
Max Process Time, you should allow for “clock drift”. For details, see
Clock Synchronization.
If you want to update the schedule and settings of a notification in a cluster, all notification instances in the cluster must be suspended or disabled for the changes to be saved. If any notification instance in the cluster is enabled, the adapter will not save the updates.
If all instances of a notification in the cluster do not have the same settings, the notification that became active first will have precedence.