Partager via

erreurs de Server-Side

  • Article

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 ayant échoué à partir 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 :

  • File d’attente du message
  • Instancie l’objet
  • Souffre d’une restauration
  • Place le message en haut de la file d’attente

Le service de composants mis en file d’attente gère cette défaillance à l’aide d’une série de files d’attente de nouvelles tentatives spécifiques à l’application. Créé lorsque le composant est installé, 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 à partir 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 sur 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 à partir 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 sur 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 à partir 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 sur 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 à partir 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 sur 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. La 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 à partir 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 sur cette file d’attente avant d’être déplacé vers la dernière file d’attente de repos. 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 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 dernière file d’attente de repos 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 de composants mis en file d’attente) ou sont vidés par Message Queuing Explorer.

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

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

  • Lorsqu’une transaction abandonne
  • Lorsqu’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 les files d’attente, puis de 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 la file d’attente principale de l’application lorsque l’application est marquée comme étant mise en file d’attente par l’outil d’administration des services de composants ou à l’aide des fonctions du Kit de développement logiciel (SDK) d’administration COM+. Le service composants mis en file d’attente permet 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 de l’application vers la file d’attente 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 de files d’attente de nouvelles tentatives. Par exemple, si vous supprimez la file d’attente de nouvelles tentatives ApplicationName_1, Nom_Application_2 et Nom_Application_3, les messages sur Nom_Application_4 seront 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 terminer un message si possible. Dans certains cas, il est possible que le message réussisse. 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 :

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

Comme les échecs persistants côté client, le service composants mis en file d’attente permet à une classe d’exception d’être associée à un composant. La classe d’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 des services de composants ou à l’aide des fonctions d’administration COM+. La classe d’exception permet au développeur d’avoir le contrôle après qu’un message a été retenté et avant que ce message ne 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 de 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 nouvelle tentative sur la dernière file d’attente de nouvelles tentatives échoue.
  3. Le 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. Les requêtes au moment de l’exécution IPlaybackControl sur la classe d’exception.
  6. L’exécution appelle IPlaybackControl ::FinalServerRetry dans la classe d’exception.
  7. L’exécution lit tous les appels de propriété et de méthode du message à la classe d’exception.
  8. Si les étapes 4 à 6 ne réussissent pas, l’exécution déplace le message vers la file d’attente 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 dernière file d’attente de repos, utilisez l’utilitaire de déplacement de message. Pour plus d’informations sur l’utilitaire de déplacement de messages, consultez Gestion des erreurs.

Client-Side erreurs

échecs de Client-Side persistants