Condividi tramite

Gestione degli errori (RPC)

  • Articolo

In RPC sincrono, un client esegue una chiamata remota che restituisce con un codice di esito positivo o negativo. RPC asincrono offre più opportunità per una chiamata a un errore e questi errori vengono gestiti in modo diverso, a seconda di dove e quando si verificano. Nella tabella seguente vengono descritti i modi in cui una chiamata può avere esito negativo e come viene gestito.

Pulizia lato client

Sintomo di errore Pulizia
Il client rileva un'eccezione quando chiama la procedura remota. Non sono necessarie chiamate API RPC. Tutti gli stati RPC sono stati puliti.
Il client riceve una notifica completa di chiamata, ma quando chiama RpcAsyncCompleteCall, riceve un codice di errore. Non sono necessarie chiamate API RPC. Tutti gli stati RPC sono stati puliti.
Il client non interrompe o interrompe l'annullamento. Il client deve attendere la notifica e chiamare RpcAsyncCompleteCall all'arrivo della notifica.

 

Nella pulizia lato server, un concetto chiave è il punto di off-off. Durante l'elaborazione lato server di una chiamata asincrona, alcune elaborazioni vengono in genere eseguite sul thread che ha ricevuto la chiamata (noto anche come thread del dispatcher ) e, facoltativamente, il thread dispatcher inserisce uno stato sufficiente in un blocco di memoria e segnala un altro thread (noto anche come thread di lavoro) per continuare l'elaborazione per la chiamata. Il momento in cui il thread dispatcher segnala correttamente che il thread di lavoro viene chiamato il punto di off-off .

Pulizia lato server

Errore rilevato Pulizia
Prima di consegnare il punto. Generare un'eccezione. Non è necessaria alcuna chiamata a RpcAsyncCompleteCall.
Dopo la consegna. Chiamare rpcAsyncAbortCall oppure, se l'errore non è irreversibile e i risultati possono comunque essere restituiti al client, RpcAsyncCompleteCall. Se il RpcAsyncCompleteCall chiamata di funzione ha esito negativo, il runtime RPC libera i parametri. L'utente non deve accedere a tali parametri. Il thread dispatcher non deve eseguire alcuna elaborazione sostanziale che potrebbe non riuscire dopo l'off point, perché non può più interrompere in modo sicuro la chiamata. In particolare, non deve generare un'eccezione dopo l'off point o il server potrebbe arrestarsi in modo anomalo.

 

Casi speciali di gestione degli errori per le pipe

Esistono casi speciali per la gestione degli errori quando si usano le pipe. L'elenco seguente illustra l'origine dell'errore e come gestire l'errore.

Origine dell'errore Modalità di gestione
Il client chiama push e la chiamata ha esito negativo. Non sono necessarie chiamate API RPC. Tutti gli stati RPC sono stati puliti.
Le chiamate client RpcAsyncCompleteCall prima che il nelle pipe venga svuotato. La chiamata ha esito negativo con il codice di errore di riempimento della pipe appropriato.
Il client chiama pull e la chiamata ha esito negativo. Non sono necessarie chiamate API RPC. Tutti gli stati RPC sono stati puliti.
Client o server chiama il push o il pull nell'ordine errato. Il runtime restituisce lo stato di errore di riempimento della pipe.
Il server chiama push o pull e la chiamata ha esito negativo. Push restituisce un codice di errore. Non è necessaria alcuna chiamata a RpcAsyncCompleteCall.
Le chiamate server RpcAsyncCompleteCall prima che le pipe siano state svuotate. La chiamata pipe restituisce uno stato di errore di riempimento della pipe.
Dopo l'invio, un'operazione di ricezione ha esito negativo. Alla successiva chiamata del server pull per ricevere i dati della pipe, viene restituito un errore.