HandleError vs incongruenze ProvideFault nel servizio del flusso di lavoro, come gestire?

Question

Nel nostro servizio di flusso di lavoro WF4, cerchiamo di essere il più robusto possibile. Una delle cose che facciamo è quello di registrare gli errori all'interno HandleError e ProvideFault (IErrorhandler). La documentazione chiaramente che HandleError sarebbe il posto giusto per fare la registrazione, ma vedo alcune cose strane:

1. vedo alcuni errori che scatenano solo ProvideFault, ma mai HandleError, un esempio è stato:

   System.NullReferenceException: Il riferimento non impostato a un'istanza di un oggetto. a System.ServiceModel.Activities.Dispatcher.DurableInstanceManager.GetInstanceAsyncResult.GetInstance() a System.ServiceModel.Activities.Dispatcher.DurableInstanceManager.GetInstanceAsyncResult..ctor

2. Ci sono anche alcuni errori che scatenano solo HandleError , ma mai ProvideFault, un esempio è stato:

   System.ServiceModel.CommunicationException: si è verificato un errore dalla pipe: la pipe è stata terminata. (109, 0x6d). a System.ServiceModel.Channels.PipeConnection.Read (Byte [] tampone, offset Int32, Int32 dimensioni, TimeSpan timeout) a System.ServiceModel.Channels.SessionConnectionReader.Receive (TimeSpan timeout)

3. Infine vi sono errori che scatenano sia, prima ProvideFault e poi HandleError (su un thread in background)

4. Se possibile, voglio registrare il corrispondente messaggio in arrivo, anche. Lo faccio con OperationContext.Current.RequestContext.RequestMessage.ToString() Questo di solito funziona solo in ProvideFault, in HandleError non abbiamo il RequestContext più

Così la mia conclusione è stata, per registrare tutti errori, devo accedere a entrambi i metodi. Ma questo porta a molte voci di registro duplicate, a causa di 3 ..

La mia soluzione attuale era di "ricordare" l'ultima eccezione registrata da ProvideFault, e ignorarla se la stessa eccezione entra in HandleError. Non mi sembra molto pulito.

Qualcuno ha un metodo migliore e affidabile per registrare tutti gli errori che possono accadere all'interno di un servizio WF?

E per favore non puntare a Logging exceptions in WCF with IErrorHandler inside HandleError or ProvideFault? come che non fornisce alcun aiuto.

Answer 1

ho visto scenario 2 accadere in un contesto diverso (BizTalk Adapter), e sembra che HandleError è chiamato perché c'è un'eccezione che si verifica l'adattatore, ma ProvideFault è non chiamato perché non c'è nessun messaggio a realtà return - l'errore si è verificato in modo tale da impedire all'adattatore di generare/leggere/tradurre effettivamente il messaggio e trasmetterlo alla pipeline. Questo sembra precludere anche un guasto messaggio dall'ottenere generato.Sembrerebbe che un errore di lettura da una pipe costituisca questo: il tuo servizio non sa se ha fallito perché non è mai nemmeno connesso o se non è riuscito a causa del fallimento del server remoto. Cose come TransactionAbortedException potrebbero causare questo, o (nel mio caso particolare), un SqlException può causarlo.

Questo dovrebbe dare qualche indizio per il caso n. 1, che non ho visto né riprodotto né riprodotto: è dovuto a una gestione errata delle eccezioni da qualche parte nella catena di messaggistica. In questo caso, è stato generato un messaggio di errore, ma qualcosa di più alto sulla catena non è riuscito a gestire l'eccezione in modo tale che sia possibile chiamare HandleError. A NullReferenceException ha senso qui - se non si gestiscono correttamente i controlli nulli è difficile dire che altro accadrà in questo caso.

Per quanto riguarda la risoluzione, probabilmente proverei ad accedere in entrambi i posti, con alcune informazioni aggiuntive che spiegano da dove proviene il registro. Sarebbe sicuro, anche se duplica la registrazione. D'altra parte, se si dispone di un elenco di eccezioni che generano uno o entrambi questi scenari, è possibile implementare la logica per verificare il tipo di eccezione (o dove si è verificata) - forse facendo meno logging se si tratta di un'eccezione che è probabile che venga gestito con l'altro metodo.