Export (0) Print
Expand All

Retry Logic

SQL Server 2000

Retry Logic

The distributor can re-attempt the delivery of notifications when a prior delivery attempt has failed. It does this on a per-protocol basis, using the /NotificationClasses/NotificationClass/Protocols/Protocol/ProtocolExecutionSettings/RetrySchedule value to determine how many retries are attempted and when they occur. If you do not want any retries, you can exclude the <RetrySchedule> node from the application definition file (ADF).

The retry logic is applied at the distributor work item level. If any notifications in a work item cannot be delivered, then the distributor work item itself is considered to have failed. The distributor can re-attempt delivery of the distributor work item at a later time, according to the information specified in the <RetrySchedule> node. When this happens, only the notifications that could not be delivered during the previous delivery attempt are included in the retry. Notifications that were successfully delivered during a previous delivery attempt are ignored during a retry. There is one exception: if a delivery failure occurs and the delivery status of a notification cannot be determined, retries are attempted that might result in the subscriber receiving duplicate notifications.

The <RetrySchedule> node contains a list of <RetryDelay> elements, each of which specifies a time duration value. After the initial failure of a distributor work item, the distributor waits the amount of time specified in the first <RetryDelay> element before re-attempting delivery of the work item. If this attempt also fails, the distributor waits the amount of time specified in the next <RetryDelay> element, and then makes another attempt. This process continues until the intervals specified by all <RetryDelay> elements have been exhausted, or until the undelivered notifications expire, whichever comes first.

Retry delays are relative to each other, not relative to the original failure time. The distributor waits the full time specified in the next <RetryDelay> element before attempting delivery again.

For example, suppose you have three retry delays specified: the first for 15 minutes, the second for 30 minutes, and the third for one hour. Assuming the initial delivery failure occurred at 13:00 GMT, the first retry occurs at 13:15 GMT, the second at 13:45 GMT, and the third at 14:45 GMT.

The <RetryDelay> values do not affect the firing schedule of the distributor. These values represent minimum delays; the actual delay between attempts might be longer. Each time the distributor fires, it determines which <RetryDelay> intervals have passed, and then re-attempts the distributor work items to which they apply.

If your server experiences prolonged downtime, more than one retry delay interval might pass without the distributor attempting a retry. If this occurs, the distributor immediately performs one retry attempt on those distributor work items that have not expired when the server comes back online. It then resumes the retry delay schedule, and waits the amount of time specified in the second missed delay interval before trying again.

For example, suppose you have four retry delays specified: the first for 15 minutes, the second for 30 minutes, the third for 45 minutes, and the fourth for one hour. The initial delivery failure occurs at 13:00 GMT, and the first retry occurs at 13:15 GMT. The server then goes down until 16:00 GMT. When the server comes back online, a retry occurs immediately, replacing the first retry delay that was missed (in this case the delay interval of 30 minutes). If this retry fails, then the next retry occurs at 16:45 GMT per the third specified retry delay interval.

Expiration Age

You can specify an expiration age for notifications with time-sensitive data. If the notifications are not delivered within the time period specified, then the distributor ceases trying to deliver them, even if there are retry delay intervals remaining. For instance, suppose you set an expiration age of two hours. If your 14:00 GMT notification batch cannot send successfully by 16:00 GMT, then those notifications expire and no further delivery attempts are made.

You specify an expiration age for notifications by using the <ExpirationAge> element in the notification class definition. If you choose not to use this element, you must exclude it from the <NotificationClass> node. In that case, notifications never expire. The distributor continues to attempt delivery of them until the retry schedule is exhausted.

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback
© 2015 Microsoft