Existe-t-il des garanties quant au moment où IIS pourrait recycler lors du traitement d'une opération WCF à sens unique?

Question

Arrière-plan

Cette question est en deux parties.

J'ai une opération WCF à sens unique hébergée dans IIS 6. Voici comment cela fonctionne:

  

_1. IIS reçoit une demande.

     

_2. IIS envoie une réponse HTTP 202 (merci, je le traiterai plus tard).

     

_3. IIS appelle mon opération WCF à sens unique.

Le contrôle passe maintenant à mon opération WCF qui effectue les opérations suivantes:

  

_4. Conservez les informations de la demande dans un magasin transactionnel durable.

     

_5. Commencez à traiter la demande dans la base de données OLTP.

     

_6. En cas d'erreur, recommencez à partir de l'étape 5 ou prenez une mesure corrective, puis nettoyez les données conservées à l'étape 4.

Question 1

Ma compréhension du moment où IIS envoie la réponse HTTP 202 est-elle correcte?

Question 2

Si IIS recycle entre l'étape 2 et l'étape 4, je pourrais perdre les informations de la demande avant que je ne sois modifié pour le conserver, mais après que le client aura accepté le message. IIS offre-t-il des garanties quant au moment où il recyclera ou non lorsque des demandes sont en attente?

PS: Veuillez excuser le formatage louche. Pour une raison quelconque, Markdown a totalement bousillé les éléments de ma liste numérotée.

Answer 1

Je ne suis pas sûr que votre hypothèse soit correcte.

Même pour une interaction à sens unique, WCF peut être très complexe avant que le 202 ne soit renvoyé; si vous utilisez l'authentification, par exemple, tout doit avoir lieu avant que la méthode soit appelée et avant que 202 soit renvoyé, de sorte que, le cas échéant, ils puissent être signalés.

Si vous utilisez wsHttpBinding, par exemple, hors de la boîte, vous verrez 2-3 échanges de messages résultant en 200 avant l'appel de la méthode réelle. il s’agit d’échanger des informations de sécurité et d’établir un contexte de sécurité.

Certes, si vous configurez votre service sans sécurité, cela ne se produira pas et le système retournera immédiatement 202, mais cela suggère qu'il doit savoir s'il peut le faire à partir de la pile WCF.

Tout cela mis à part - je ne suis pas sûr de ce que vous essayez d'atteindre - à quel recyclage IIS faites-vous référence? Je ne suis pas du tout un expert sur IIS, mais je doute que cela puisse recycler l'hôte pendant l'exécution de quelque chose. Si vous faites référence à quelqu'un qui restreint manuellement le pool d'applications (ou IIS, ou la machine d'ailleurs), je doute que vous puissiez faire beaucoup.

Si vous devez savoir avec certitude qu'un message n'est pas perdu, je ne peux le garantir que par l'utilisation d'une messagerie fiable, d'une manière ou d'une autre, qui ne reconnaît que les demandes persistantes dans un magasin durable;

Answer 2

À mon avis, il y a plusieurs choses que je suggérerais:

À ma connaissance, le seul moyen dont je dispose pour gérer le recyclage des processus dans IIS consiste à examiner le pool d'applications utilisé par votre site Web. Si vous ouvrez le gestionnaire IIS - > Pools d'applications - > sélectionnez votre pool, puis cliquez avec le bouton droit de la souris sur les propriétés. Dans l'onglet Recyclage, vous trouverez des options qui pourraient vous aider. Je suppose que cela ne garantit pas que vous ne perdrez pas les demandes dans un recyclage, mais que vous fixez un délai plus long réduisant la probabilité d'un tel cas.

Cependant, il semble que le type de système que vous envisagez de créer soit un candidat idéal pour MSMQ, qui peut fournir des demandes de service asynchrones correctement mises en file d'attente avec très peu de frais généraux ou de plomberie manuelle. Cela vous permettrait d'éviter complètement le problème du recyclage du processus. Je ne suis pas sûr que ce soit une option pour votre scénario, mais cela pourrait être quelque chose à examiner.