Partager via

Gestion des erreurs (RPC)

  • Article

Dans RPC synchrone, un client effectue un appel distant qui retourne avec un code de réussite ou d’échec. Rpc asynchrone offre davantage d’opportunités d’échec d’un appel, et ces échecs sont gérés différemment, selon l’endroit et le moment où ils se produisent. Le tableau suivant décrit les façons dont un appel peut échouer et comment il est géré.

Nettoyage côté client

Symptôme d’échec Nettoyage
Le client intercepte une exception lorsqu’il appelle la procédure distante. Aucun appel d’API RPC n’est nécessaire. Tout l’état RPC a été nettoyé.
Le client reçoit une notification complète d’appel, mais lorsqu’il appelle RpcAsyncCompleteCall, il reçoit un code d’erreur. Aucun appel d’API RPC n’est nécessaire. Tout l’état RPC a été nettoyé.
Le client émet un annulation non abortive ou abortive. Le client doit attendre la notification et appeler RpcAsyncCompleteCall à l’arrivée de la notification.

 

Dans le nettoyage côté serveur, un concept clé est le point de remise. Pendant le traitement côté serveur d’un appel asynchrone, certains traitements sont généralement effectués sur le thread qui a reçu l’appel (également appelé thread de répartiteur ), puis, éventuellement, le thread de répartiteur place suffisamment d’état dans un bloc de mémoire et signale un autre thread (également appelé thread de travail) pour continuer le traitement de l’appel. Moment où le thread de répartiteur signale avec succès que le thread de travail est appelé le point de remise .

Nettoyage côté serveur

Erreur rencontrée Nettoyage
Avant le point de remise. Lever une exception. Aucun appel à RpcAsyncCompleteCall est nécessaire.
Après le point de remise. Appelez RpcAsyncAbortCall ou, si l’erreur n’est pas irrécupérable et que les résultats peuvent toujours être retournés au client, RpcAsyncCompleteCall. Si l’appel de fonction RpcAsyncCompleteCall échoue, le runtime RPC libère les paramètres. L’utilisateur ne doit pas accéder à ces paramètres. Le thread de répartiteur ne doit pas effectuer de traitement important qui peut échouer après le point de remise, car il ne peut plus abandonner l’appel en toute sécurité. Plus précisément, il ne doit pas lever d’exception après le point de remise, ou le serveur peut se bloquer.

 

Cas spéciaux de gestion des erreurs pour les canaux

Il existe des cas spéciaux pour la gestion des erreurs lors de l’utilisation de canaux. La liste suivante explique la source de l’échec et comment gérer l’erreur.

Source de l’échec Comment géré
Les appels clients push et l’appel échouent. Aucun appel d’API RPC n’est nécessaire. Tout l’état RPC a été nettoyé.
Les appels clients RpcAsyncCompleteCall avant que les dans canaux soient vidés. L’appel échoue avec le code d’erreur de remplissage de canal approprié.
Les appels clients extrayent et l’appel échoue. Aucun appel d’API RPC n’est nécessaire. Tout l’état RPC a été nettoyé.
Appels client ou serveur push ou pull dans l’ordre incorrect. L’exécution retourne l’état d’erreur de remplissage du canal.
Les appels serveur push ou pull et l’appel échoue. L’envoi renvoie un code d’échec. Aucun appel à RpcAsyncCompleteCall est nécessaire.
Les appels de serveur RpcAsyncCompleteCall avant que les canaux n’aient été vidés. L’appel de canal retourne un état d’erreur de remplissage de canal.
Une fois la distribution terminée, une opération de réception échoue. La prochaine fois que le serveur appelle l’extraction pour recevoir des données de canal, une erreur est retournée.