Specifying Delivery Protocol Execution Settings

Článek
12/03/2008

When you configure a delivery protocol, you can define several execution settings that configure delivery retry, failure, and time-out handling. This topic explains how to specify these delivery protocol execution settings.

Retrying Notification Delivery

When notifications fail delivery, the distributor can attempt to deliver the notifications again. You configure a retry schedule for each delivery protocol used by a notification class.

The retry logic is applied at the distributor work-item level. If any notifications in a work item cannot be delivered, the distributor work item itself is considered to have failed. The distributor can retry delivery of the distributor work item at a later time, according to the specified schedule.

When the distributor retries a work item, only the notifications that could not be delivered during the previous delivery attempt are sent again. However, if an error occurs that prevents the distributor from updating a notification's delivery status, the distributor may retry delivery and potentially resend a duplicate notification on the next retry attempt.

When you configure a retry schedule, you specify one or more retry delay values. If a notification fails delivery, the distributor waits to pick up the work item again until the amount of interval specified by the first retry delay value elapses. If notifications fail delivery again, the distributor will wait for the second retry delay and then attempt delivery again. This process continues until all retry delay values have been exhausted, or until the undelivered notifications expire, whichever comes first.

Note

You specify an expiration age per notification class, not per delivery protocol. For more information, see Specifying the Notification Expiration Age.

Example

The following table shows how the distributor retries notification delivery with three retry delay values.

Initial delivery attempt	1:00
First retry delay = 15 minutes	1:15
Second retry delay = 30 minutes	1:45
Third retry delay = 60 minutes	2:45

The retry delay values do not affect the firing schedule of the distributor. These values represent minimum delays; the actual delay between attempts might be longer.

If your server experiences prolonged downtime, more than one retry delay interval might elapse 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 next delay interval before trying again.

To specify a retry schedule

If you are defining an application through XML, define individual retry delays in the RetrySchedule Element (ADF).
If you are defining an application programmatically, define individual retry delays in a ProtocolRetrySchedule object and add them to a ProtocolRetryScheduleCollection in a NotificationClassProtocol object using the ProtocolRetrySchedules property (NMO).

Logging Delivery Failures

The distributor writes entries to the Windows application log to document notification delivery failures. You configure how and when the distributor logs delivery failure events for each delivery protocol.

Important

Notification Services receives limited error feedback from the external delivery systems. Most failures result in a generic "delivery failure" error in the event log. Consistent delivery failures might indicate a configuration issue. To verify the delivery configuration, review delivery channel settings in the instance configuration and the protocol field values in the application definition.

The first property you can configure is how many failures must occur before the distributor logs an event in the application log. The second property you can configure is the minimum interval between logging events, regardless of the number of failures. These two settings allow you to control how many events the distributor writes to the application log and prevents the application log from being flooded when several failures occur in a short amount of time.

For example, if the number of failures is set to 5 and the interval is set to 10 minutes, five failures must occur before the distributor logs an error. After 10 minutes, the failure count begins again. After another five failures, the distributor writes another event to the application log.

When developing an application, you might want to use the default values of one failure and zero minutes. However, when an application is in production, consider using higher values to balance between the need for failure information and the desire to minimize excessive logging.

Note

The NSDiagnosticDeliveryChannel (Transact-SQL) and NSDiagnosticFailedNotifications (Transact-SQL) stored procedures can be helpful in troubleshooting delivery failures.

To configure the number of delivery failures before logging an event

If you are defining an application through XML, define the number of delivery failures before logging an event in the FailuresBeforeLoggingEvent Element (ADF).
If you are defining an application programmatically, define the number of delivery failures before logging an event using the FailuresBeforeEventLog property (NMO).

To configure the interval between logging

If you are defining an application through XML, define the interval between logging in the FailureEventLogInterval Element (ADF).
If you are defining an application programmatically, define the interval between logging using the FailureEventLogInterval property (NMO).

Stopping Delivery After Consecutive Failures

In cases where delivery failure occurs because of a prolonged network outage, rather than transient network conditions, the distributor can stop delivery attempts within a work item to avoid flooding the network.

You can specify how many consecutive delivery failures must occur within a work item before the distributor cancels additional delivery attempts on notifications in that work item. When the limit is reached, the distributor writes a message to the application log and then marks the work item as failed. In this case, there might be notifications in the work item that were never attempted. If there is a retry schedule, the distributor will pick up the work item at the next retry interval and retry both the failed notifications and those that were never attempted.

To configure the number of consecutive failures before stopping delivery

If you are defining an application through using XML, define the number of consecutive failures in the FailuresBeforeAbort Element (ADF).
If you are defining an application programmatically, define the number of consecutive failures using the FailuresBeforeAbort property (NMO).

Limiting Multicast Recipients

For each delivery protocol, you also can limit the number of subscribers who can receive a single multicast. For more information on multicast, see Specifying Digest or Multicast Delivery.

When you limit the number of multicast recipients, the distributor stops adding subscribers to the multicast recipient list when the limit is reached. The distributor then starts a new list and adds subscribers to the new list until the limit is reached. This process continues until all multicast notifications within a work item are added to multicast recipient lists.

Important

Multicast settings are not available in SQL Server 2005 Standard Edition.

To configure the multicast recipient limit

If you are defining an application through XML, define the multicast recipient limit in the MulticastRecipientLimit Element (ADF).
If you are defining an application programmatically, define the multicast recipient limit using the MulticastRecipientLimit property (NMO).

Setting a Work Item Time-Out

When the distributor picks up a work item, it calls the content formatter to format the notifications and the delivery protocol to package and deliver the notifications. If a work item is very large, or if distribution is blocked for any reason, the work item can consume one thread of the distributor and delay the processing of other notifications.

If you specify a work item time-out for a delivery protocol, the distributor releases the work item after the specified amount of time. The distributor marks the work item as having failed and picks up the work item again if the delivery protocol has a retry schedule.

To configure a work item time-out

If you are defining an application through XML, define the work item time-out value in the WorkItemTimeout Element (ADF).
If you are defining an application programmatically, define the work item time-out value using the WorkItemTimeout property (NMO).

Sdílet prostřednictvím