erreurs de Server-Side

L’écouteur et le joueur travaillent ensemble pour traiter les messages incohérents. Si une transaction en cours de lecture échoue, Message Queuing déplace le message d’entrée vers la file d’attente d’entrée. Le joueur abandonne la transaction s’il reçoit un HRESULT défaillant du composant serveur ou s’il intercepte une exception. Si le problème persiste, l’écouteur peut boucler en continu dans le modèle suivant :

• Supprime le message de la file d’attente
• Instancie l’objet
• Subit une restauration
• Replace le message en haut de la file d’attente

Le service composants mis en file d’attente gère cet échec à l’aide d’une série de files d’attente de nouvelles tentatives spécifiques à l’application. Créé lors de l’installation du composant, il existe sept files d’attente pour chaque application, comme suit :

1. File d’attente d’entrée normale. Le nom de cette file d’attente est le nom de l’application COM+. Il s’agit d’une file d’attente publique Message Queuing.

2. Première file d’attente de nouvelles tentatives. Les messages sont déplacés ici si la transaction échoue à plusieurs reprises lors du traitement des messages de la file d’attente d’entrée normale. Les messages de cette file d’attente sont traités après une minute. Un message peut être retenté trois fois dans cette file d’attente avant d’être déplacé vers l’arrière de la deuxième file d’attente de nouvelles tentatives. Cette file d’attente est nommée ApplicationName_0. Cette file d’attente est une file d’attente Message Queuing privée.

3. Deuxième file d’attente de nouvelles tentatives. Les messages sont déplacés ici si la transaction échoue à plusieurs reprises lors du traitement des messages de la première file d’attente de nouvelles tentatives. Les messages de cette file d’attente sont traités après deux minutes. Un message peut être retenté trois fois dans cette file d’attente avant d’être déplacé vers l’arrière de la troisième file d’attente de nouvelles tentatives. Cette file d’attente est nommée ApplicationName_1. Cette file d’attente est une file d’attente Message Queuing privée.

4. Troisième file d’attente de nouvelles tentatives. Les messages sont déplacés ici si la transaction échoue à plusieurs reprises lors du traitement des messages de la deuxième file d’attente de nouvelles tentatives. Les messages de cette file d’attente sont traités après quatre minutes. Un message peut être retenté trois fois dans cette file d’attente avant d’être déplacé vers l’arrière de la quatrième file d’attente de nouvelles tentatives. Cette file d’attente est nommée ApplicationName_2. Cette file d’attente est une file d’attente Message Queuing privée.

5. Quatrième file d’attente de nouvelles tentatives. Les messages sont déplacés ici si la transaction échoue à plusieurs reprises lors du traitement des messages de la troisième file d’attente de nouvelles tentatives. Les messages de cette file d’attente sont traités après huit minutes. Un message peut être retenté trois fois dans cette file d’attente avant d’être déplacé vers la cinquième file d’attente de nouvelles tentatives. Cette file d’attente est nommée ApplicationName_3. Cette file d’attente est une file d’attente Message Queuing privée.

6. Cinquième file d’attente de nouvelles tentatives. Les messages sont déplacés ici si la transaction échoue à plusieurs reprises lors du traitement des messages de la quatrième file d’attente de nouvelles tentatives. Les messages de cette file d’attente sont traités après seize minutes. Un message peut être retenté trois fois dans cette file d’attente avant d’être déplacé vers la file d’attente de repos finale. Cette file d’attente est nommée ApplicationName_4. Il s’agit d’une file d’attente Message Queuing privée.

7. File d’attente de repos finale spécifique à l’application. Les messages sont déplacés ici si la transaction abandonne à plusieurs reprises lors d’une tentative dans la cinquième file d’attente de nouvelles tentatives. Cette file d’attente est nommée ApplicationName_DeadQueue. Il s’agit d’une file d’attente Message Queuing privée. La file d’attente de repos finale n’est pas prise en charge par un écouteur de file d’attente. Les messages restent ici jusqu’à ce qu’ils soient déplacés manuellement (peut-être par l’utilitaire de déplacement de messages des composants en file d’attente) ou vidés par message Queuing Explorer.

Les messages qui ne sont pas lisibles, car il est clair que chaque nouvelle tentative échoue peuvent être déplacés directement vers la file d’attente de repos finale spécifique à l’application sans être avancés via tous les niveaux de nouvelle tentative.

Le joueur émet un événement COM+ pour informer les parties intéressées que les messages ne peuvent pas être lus. Les événements COM+ sont émis dans les situations suivantes :

• Quand une transaction abandonne
• Quand un message est déplacé d’une file d’attente vers une autre
• Lorsqu’un message est déposé dans la file d’attente de repos finale

Les messages peuvent être modifiés avant de passer d’une file d’attente à une autre. Le mécanisme de sécurité des composants mis en file d’attente COM+ permet de déplacer un message pour réessayer des files d’attente, puis de le réinsérer dans la file d’attente d’entrée initiale de l’application. Pour plus d’informations sur la sécurité des composants mis en file d’attente, consultez Sécurité des composants mis en file d’attente.

Les files d’attente de nouvelles tentatives sont créées avec l’main file d’attente d’application lorsque l’application est marquée comme mise en file d’attente par l’outil d’administration des services de composants ou à l’aide des fonctions du SDK d’administration COM+. Le service des composants mis en file d’attente offre une flexibilité dans le mécanisme de nouvelle tentative en autorisant la suppression des files d’attente de nouvelles tentatives. Par exemple, si toutes les files d’attente de nouvelles tentatives sont supprimées, un message indiquant que les abandons persistants sont déplacés directement de la file d’attente d’application vers la file d’attente de repos finale spécifique à l’application. En supprimant une ou plusieurs files d’attente de nouvelles tentatives, le nombre et la longueur des nouvelles tentatives peuvent être réduits. Si les files d’attente sont supprimées de la séquence de nouvelles tentatives, le minutage des files d’attente restantes correspond à la position dans la séquence des files d’attente de nouvelles tentatives. Par exemple, si vous supprimez la file d’attente de nouvelles tentatives ApplicationName_1, ApplicationName_2 et ApplicationName_3, les messages sur ApplicationName_4 sont traités comme si la file d’attente était la deuxième file d’attente de nouvelles tentatives.

Le mécanisme de nouvelle tentative est conçu pour compléter un message si possible. Dans certains cas, le message peut ne pas réussir. Par exemple, un client peut tenter de retirer de l’argent d’un compte dont les fonds sont insuffisants. Dans ces circonstances, vous pouvez gérer l’erreur de plusieurs façons, notamment les suivantes :

• Générer un diagnostic et émettre un avertissement
• Créer une transaction de compensation
• Ignorer le problème et ignorer le message

À l’instar des défaillances persistantes côté client, le service de composants mis en file d’attente autorise l’association d’une classe d’exception à un composant. La classe exception est associée au composant à l’aide de l’onglet Avancé dans la page des propriétés du composant de l’outil d’administration Services de composants ou à l’aide des fonctions d’administration COM+. La classe exception permet au développeur de contrôler une fois qu’un message a été retenté et avant que ce message soit déplacé vers la file d’attente de repos finale spécifique à l’application. Pour plus d’informations sur la classe d’exception, consultez Échecs Client-Side persistants.

Voici la séquence d’événements pour la gestion des exceptions côté serveur :

1. Le message est déplacé via les files d’attente de nouvelles tentatives spécifiques à l’application disponibles.
2. La dernière tentative de la dernière file d’attente de nouvelles tentatives échoue.
3. L’exécution du service composants mis en file d’attente récupère le composant cible à partir du message et recherche une classe d’exception.
4. L’exécution instancie la classe d’exception.
5. L’exécution interroge IPlaybackControl sur la classe d’exception.
6. L’exécution appelle IPlaybackControl::FinalServerRetry dans la classe exception.
7. L’exécution lit tous les appels de propriété et de méthode du message à la classe exception.
8. Si les étapes 4 à 6 ne réussissent pas, l’exécution déplace le message dans la file d’attente de repos finale spécifique à l’application.

Si vous devez intervenir dans le processus décrit ci-dessus ou si vous devez déplacer un message incohérent hors de sa file d’attente de repos finale, utilisez l’utilitaire de déplacement de messages. Pour plus d’informations sur l’utilitaire de déplacement de messages, consultez Gestion des erreurs.

Rubriques connexes

Erreurs côté client

Échecs de Client-Side persistants