Spécification des paramètres d'exécution d'un protocole de remise

Lorsque vous configurez un protocole de remise, vous pouvez définir plusieurs paramètres d'exécution qui configurent la gestion des tentatives de remise, des échecs et des délais. Cette rubrique explique comment spécifier ces paramètres d'exécution de protocole de remise.

Nouvelle tentative de remise de notifications

Lorsque la remise des notifications échoue, le serveur de distribution peut réessayer d'effectuer la remise des notifications. Vous configurez une planification de nouvelle tentative pour chaque protocole de remise utilisé par une classe de notification.

La logique de tentative est appliquée au niveau élément de travail du serveur de distribution. Si des notifications dans un élément de travail ne peuvent pas être remises, l'élément de travail du serveur de distribution lui-même est supposé avoir échoué. Le serveur de distribution peut réessayer ultérieurement la remise de l'élément de travail du serveur de distribution selon la planification spécifiée.

Quand le serveur de distribution réessaye un élément de travail, seules les notifications qui n'ont pas pu être transmises lors de la précédente tentative de remise sont à nouveau envoyées. Si une erreur se produit qui empêche le serveur de distribution de mettre à jour l'état de remise d'une notification, le serveur de distribution peut toutefois réessayer la remise et éventuellement renvoyer une notification dupliquée lors de la tentative suivante.

Lorsque vous configurez une planification de nouvelle tentative, vous spécifiez une ou plusieurs valeurs de délai entre reprises. Si la remise d'une notification échoue, le serveur de distribution attend pour récupérer à nouveau l'élément de travail jusqu'à ce que la durée de l'intervalle spécifié par la première valeur de délai entre reprises soit écoulé. Si la remise des notifications échoue à nouveau, le serveur de distribution attend pendant la durée du deuxième délai entre reprises, puis tente à nouveau la remise. Ce processus se poursuit jusqu'à ce que toutes les valeurs de délai entre reprises aient été utilisées ou jusqu'à l'expiration des notifications non transmises, le premier événement étant pris en compte.

Remarque :
Vous spécifiez une période d'expiration par classe de notification et non par protocole de remise. Pour plus d'informations, consultez Spécification de la période de conservation des notifications.

Exemple

Le tableau suivant répertorie comment le serveur de distribution réessaye la remise de notification avec trois valeurs de délai entre reprises.

Tentative initiale de remise	1:00
Premier délai entre reprises = 15 minutes	1:15
Deuxième délai entre reprises = 30 minutes	1:45
Troisième délai entre reprises = 60 minutes	2:45

Les valeurs de délai entre reprises n'ont pas d'incidence sur la planification de l'activation du serveur de distribution. Ces valeurs représentent les délais minimaux ; le délai véritable entre tentatives peut être plus long.

Si votre serveur connaît un temps d'arrêt prolongé, il peut s'écouler plusieurs intervalles de délai entre reprises sans nouvelle tentative de la part du serveur de distribution. Dans un tel cas, le serveur de distribution effectue immédiatement une nouvelle tentative sur les éléments de travail du serveur de distribution qui n'ont pas expiré quand le serveur revient en ligne. Il reprend ensuite la planification de délai entre reprises et attend pendant la durée spécifiée dans l'intervalle du délai suivant avant de réessayer.

Pour spécifier une planification de nouvelle tentative

• Si vous définissez une application par le biais XML, définissez les délais individuels entre reprises dans l'RetrySchedule Element (ADF).
• Si vous définissez une application par programme, définissez les délais individuels entre reprises dans un objet ProtocolRetrySchedule et ajoutez-les à un ProtocolRetryScheduleCollection d'un objet NotificationClassProtocol à l'aide de la propriété ProtocolRetrySchedules (NMO).

Enregistrement des échecs de remise dans le journal

Le serveur de distribution écrit des entrées dans le journal d'application Windows pour documenter les échecs de remise de notification. Vous configurez comment et quand le serveur de distribution enregistre les événements d'échec de remise pour chaque protocole de remise.

Important :

Notification Services reçoit un retour d'informations limité de la part des systèmes de remise externes. La plupart des échecs produisent une erreur générique « Échec de la remise » dans le journal des événements. Des échecs réguliers de la remise peuvent indiquer un problème de configuration. Pour contrôler la configuration de la remise, vérifiez les paramètres de canal de remise dans la configuration d'instance et les valeurs de champ de protocole dans la définition d'application.

La première propriété que vous pouvez configurer est le nombre d'échecs qui doivent survenir avant que le serveur de distribution enregistre un événement dans le journal des applications. La deuxième propriété que vous pouvez configurer est l'intervalle minimal entre les événements d'enregistrement, quel que soit le nombre d'échecs. Ces deux paramètres permettent de contrôler le nombre d'événements que le serveur de distribution écrit dans le journal d'application et d'éviter que ce dernier ne soit submergé quand plusieurs échecs se produisent sur un faible intervalle de temps.

Par exemple, si le nombre d'échecs est défini sur 5 et si l'intervalle est défini sur 10 minutes, cinq échecs doivent survenir avant que le serveur de distribution enregistre une erreur. Après 10 minutes, le comptage du nombre d'échecs reprend. Après cinq autres échecs, le serveur de distribution écrit un autre événement dans le journal de l'application.

Vous pouvez, lors du développement d'une application, choisir d'utiliser les valeurs par défaut, à savoir un seul échec et zéro minute. Si une application est en production, envisagez toutefois d'utiliser des valeurs supérieures pour parvenir à un équilibre entre les informations nécessaires relatives aux échecs et le désir de limiter la quantité des enregistrements.

Remarque :
NSDiagnosticDeliveryChannel (Transact-SQL) et les procédures stockées NSDiagnosticFailedNotifications (Transact-SQL) peuvent être utiles pour le dépannage des échecs de remise.

Pour configurer le nombre d'échecs de la remise avant l'enregistrement d'un événement

• Si vous définissez une application par le biais de XML, définissez le nombre d'échecs de la remise avant l'enregistrement d'un événement dans l'FailuresBeforeLoggingEvent Element (ADF).
• Si vous définissez une application par programme, définissez le nombre d'échecs de la remise avant d'enregistrer un événement à l'aide de la propriété FailuresBeforeEventLog (NMO).

Pour configurer l'intervalle entre les enregistrements

• Si vous définissez une application par le biais de XML, définissez l'intervalle entre les enregistrements dans l'FailureEventLogInterval Element (ADF).
• Si vous définissez une application par programme, définissez l'intervalle entre les enregistrements à l'aide de la propriété FailureEventLogInterval (NMO).

Arrêt de la remise après des échecs consécutifs

Dans les cas où une erreur de remise se produit à cause d'une panne réseau prolongée au lieu d'un état transitoire du réseau, le serveur de distribution peut arrêter des tentatives de remise dans un élément de travail pour éviter de submerger le réseau.

Vous pouvez spécifier le nombre d'échecs de remise consécutifs qui doivent survenir dans un élément de travail avant que le serveur de distribution annule les tentatives de remise supplémentaires des notifications de cet élément de travail. Lorsque la limite est atteinte, le serveur de distribution écrit un message dans le journal d'application et marque ensuite l'élément de travail en échec. Dans ce cas, il est possible que des notifications dans l'élément de travail n'aient jamais été tentées. S'il existe une planification de nouvelle tentative, le serveur de distribution récupère l'élément de travail à l'intervalle de nouvelle tentative suivant et réessaie les notifications ayant échoué et celles qui n'ont jamais été tentées.

Pour configurer le nombre d'échecs consécutifs avant d'arrêter la remise

• Si vous définissez une application par le biais de XML, définissez le nombre d'échecs consécutifs dans l'FailuresBeforeAbort Element (ADF).
• Si vous définissez une application par programme, définissez le nombre d'échecs consécutifs à l'aide de la propriété FailuresBeforeAbort (NMO).

Restriction des destinataires de multidiffusion

Pour chaque protocole de remise, vous pouvez également limiter le nombre d'abonnés qui peuvent recevoir une seule multidiffusion. Pour plus d'informations sur la multidiffusion, consultez Spécification de la livraison de type digest ou par multidiffusion.

Quand vous limitez le nombre de destinataires de multidiffusion, le serveur de distribution arrête d'ajouter des abonnés à la liste des destinataires de multidiffusion lorsque la limite est atteinte. Le serveur de distribution commence alors une nouvelle liste et y ajoute les abonnés jusqu'à ce que la limite soit atteinte. Ce processus se poursuit jusqu'à ce que toutes les notifications de multidiffusion dans un élément de travail soient ajoutées aux listes des destinataires de multidiffusion.

Important :
Les paramètres de multidiffusion ne sont pas disponibles dans SQL Server 2005 Standard Edition.

Pour configurer la limite des destinataires de multidiffusion

• Si vous définissez une application par le biais de XML, définissez la limite des destinataires de multidiffusion dans l'MulticastRecipientLimit Element (ADF).
• Si vous définissez une application par programme, définissez la limite des destinataires de multidiffusion à l'aide de la propriété MulticastRecipientLimit (NMO).

Définition d'un délai d'attente d'un élément de travail

Quand le serveur de distribution récupère un élément de travail, il appelle le module de formatage de contenu pour formater les notifications et le protocole de remise pour compresser et remettre les notifications. Si un élément de travail est très volumineux ou si la distribution est bloquée pour une raison quelconque, l'élément de travail peut consommer un thread du serveur de distribution et reporter le traitement des autres notifications.

Si vous spécifiez un délai d'attente d'élément de travail pour un protocole de remise, le serveur de distribution libère l'élément de travail après la durée spécifiée. Le serveur de distribution marque l'élément de travail en échec et récupère à nouveau l'élément de travail si le protocole de remise possède une planification de nouvelle tentative.

Pour configurer un délai d'attente d'élément de travail

• Si vous définissez une application par le biais de XML, définissez la valeur de délai d'attente d'élément de travail dans l'WorkItemTimeout Element (ADF).
• Si vous définissez une application par programme, définissez la valeur de délai d'attente d'élément de travail à l'aide de la propriété WorkItemTimeout (NMO).

Voir aussi

Concepts

Configuration de la journalisation sur le serveur de distribution

Autres ressources

Procédures stockées de Notification Services (Transact-SQL)
Configuration des protocoles de remise
Définition des classes de notification
Définition des applications Notification Services

Aide et Informations

Assistance sur SQL Server 2005