Felhantering (RPC)

I synkron RPC gör en klient ett fjärranrop som returnerar med antingen en lyckad kod eller en felkod. Asynkron RPC ger fler möjligheter för ett anrop att misslyckas, och dessa fel hanteras på olika sätt, beroende på var och när de inträffar. I följande tabell beskrivs hur ett anrop kan misslyckas och hur det hanteras.

Rensa på klientsidan

Felsymptom	Rensning
Klienten fångar upp ett undantag när den anropar fjärrproceduren.	Inga RPC API-anrop krävs. Allt RPC-tillstånd har rensats.
Klienten får ett fullständigt samtalsmeddelande, men när den anropar RpcAsyncCompleteCallfår den en felkod.	Inga RPC API-anrop krävs. Allt RPC-tillstånd har rensats.
Klientproblem som inte avbryts eller avbryts.	Klienten måste vänta på meddelandet och anropa RpcAsyncCompleteCall- när meddelandet kommer.

 

Vid rensning på serversidan är ett nyckelkoncept hand-off-punkten. Under bearbetningen på serversidan av ett asynkront anrop utförs en del bearbetning vanligtvis på tråden som tog emot anropet (kallas även dispatcher thread), och sedan, om du vill, lägger dispatcher-tråden tillräckligt med tillstånd i ett minnesblock och signalerar en annan tråd (även känd som arbetstråd) för att fortsätta bearbetningen för anropet. Det ögonblick då dispatcher-tråden signalerar att arbetstråden kallas hand-off-punkt.

Rensning på serversidan

Fel påträffades	Rensning
Före hand-off punkt.	Utlöser undantag. Det krävs inget anrop till RpcAsyncCompleteCall.
Efter hand-off punkt.	Anropa RpcAsyncAbortCall eller, om felet inte är allvarligt och resultatet fortfarande kan returneras till klienten, RpcAsyncCompleteCall. Om RpcAsyncCompleteCall funktionsanrop misslyckas frigör RPC-körningen parametrarna. Användaren får inte komma åt dessa parametrar. Dispatcher-tråden får inte utföra någon betydande bearbetning som kan misslyckas efter handavsändarpunkten, eftersom den inte längre kan avbryta anropet på ett säkert sätt. Mer specifikt får det inte utlösa ett undantag efter hand off-punkten, eller så kan servern krascha.

 

Särskilda felhanteringsfall för rör

Det finns särskilda fall för felhantering vid användning av rör. I följande lista förklaras orsaken till felet och hur du hanterar felet.

Felkällan	Så här hanteras
Klienten anropar push och anropet misslyckas.	Inga RPC API-anrop krävs. Allt RPC-tillstånd har rensats.
Klientanrop RpcAsyncCompleteCall innan i rör töms.	Anropet misslyckas med rätt felkod för rörfyllning.
Klienten anropar pull och anropet misslyckas.	Inga RPC API-anrop krävs. Allt RPC-tillstånd har rensats.
Antingen anropar klienten eller servern push-överföring eller hämtning i fel ordning.	Körning returnerar felstatus för rörfyllning.
Servern anropar push eller pull och anropet misslyckas.	Push returnerar en felkod. Det krävs inget anrop till RpcAsyncCompleteCall.
Serveranrop RpcAsyncCompleteCall innan rören har tömts.	Pipe-anropet returnerar status för rörfyllningsfel.
Efter sändningen misslyckas en mottagningsåtgärd.	Nästa gång servern anropar pull för att ta emot rördata returneras ett fel.