Ci sono garanzie su quando IIS potrebbe riciclare durante l'elaborazione di un'operazione WCF a 1 via?

Question

Sfondo

Questa domanda è divisa in due parti.

Ho un'operazione WCF a senso unico ospitata in IIS 6. Quanto segue è la mia comprensione di come funziona:

  

_1. IIS riceve una richiesta.

     

_2. IIS invia una risposta HTTP 202 (grazie, lo elaborerò più avanti).

     

_3. IIS chiama la mia operazione WCF a senso unico.

Ora il controllo passa all'operazione WCF che esegue le seguenti operazioni:

  

_4. Persistere le informazioni della richiesta in un negozio transazionale e durevole.

     

_5. Inizia l'elaborazione della richiesta nel database OLTP.

     

_6. Se si verifica un errore, ripetere dal passaggio 5 o eseguire alcune azioni correttive, quindi ripulire i dati persistenti al passaggio 4.

Domanda 1

La mia comprensione di quando IIS invia la risposta HTTP 202 è corretta?

Domanda 2

Se IIS ricicla tra il passaggio 2 e il passaggio 4, potrei perdere le informazioni della richiesta prima di avere una modifica per persistere, ma dopo che il client pensa che ho accettato il messaggio. Esistono garanzie fornite da IIS su quando verrà o non verrà riciclato in caso di richieste in sospeso?

---

PS: ti preghiamo di scusare la formattazione non corretta. Per qualche ragione, il markdown ha rovinato totalmente le mie voci di elenco numerate.

Answer 1

Non sono sicuro che la tua ipotesi sia corretta.

Anche per l'interazione a senso unico, WCF può diventare molto invariato prima che il 202 venga restituito; se si utilizza l'autenticazione, ad esempio, tutto deve avvenire prima che venga chiamato il metodo e prima che venga restituito 202, in modo che se ci sono problemi possano essere segnalati.

Se si utilizza wsHttpBinding, ad esempio, immediatamente disponibile, verranno visualizzati 2-3 scambi di messaggi che generano 200 prima della chiamata effettiva al metodo. questo serve a scambiare informazioni sulla sicurezza e stabilire un contesto di sicurezza.

Certamente, se hai configurato il tuo servizio per non avere sicurezza, questo non accadrà e restituirà immediatamente 202, ma questo suggerisce che deve sapere se può farlo dallo stack WCF.

A parte questo, non sono sicuro di ciò che stai cercando di raggiungere, a quale riciclaggio IIS ti riferisci? Non sono affatto un esperto di IIS, ma dubito che riciclerebbe l'host mentre qualcosa sta eseguendo attivamente; se ti riferisci a qualcuno che limita manualmente il pool di applicazioni (o IIS o la macchina), dubito che ci sia molto che puoi fare.

Se devi sapere con certezza che un messaggio non viene perso, l'unico modo che conosco per garantirlo è utilizzando la messaggistica affidabile in un modo o nell'altro, che riconosce solo le richieste una volta persistute in un negozio durevole;

Answer 2

Secondo me, ci sono un paio di cose che suggerirei:

L'unico modo che conosco per gestire il riciclo dei processi in IIS è esaminare il pool di applicazioni utilizzato dal tuo sito Web. Se apri Gestione IIS - > Pool di applicazioni - > seleziona il tuo Pool quindi fai clic con il pulsante destro del mouse sulle proprietà, nella scheda Riciclaggio ci sono opzioni che potrebbero aiutarti. Immagino che ciò non garantisca che non perderai le richieste in un riciclo, ma impostare un tempo più lungo riducendo la probabilità di un caso del genere.

Tuttavia, sembra che il tipo di sistema che stai cercando di costruire sia un candidato ideale per MSMQ, in grado di fornire richieste di servizio asincrone che sono messe correttamente in coda con un minimo sovraccarico o un impianto idraulico manuale. Ciò consentirebbe di evitare del tutto il problema del riciclaggio del processo. Non sono sicuro che sia un'opzione per il tuo scenario, ma potrebbe essere qualcosa da esaminare.