arrêt progressif du rôle des travailleurs Azure

Question

Considérons un rôle de travailleur que:

1. héberge un serveur WCF
2. Ecoutes à quelques files d'attente Azure Queues de stockage et de bus

Les méthodes de traitement effectuent certains E/S de stockage Azure, HttpClient appels à des API externes et des appels Entity Framework. Maintenant, je veux que mon rôle de travailleur gracieusement l'arrêt si toutes les opérations en cours sont terminées ou annulées de manière gérée:

1. Arrêtez d'accepter toutes les demandes entrantes une fois RoleEntryPoint.OnStop() est déclenchée. Est-ce que Azure le fait pour moi? Sinon, comment puis-je l'appliquer?
2. Allow N secondes pour toute opération en attente pour compléter
3. Après N secondes annule toute opération de gauche. L'annulation ne doit pas dépasser M secondes de sorte que N + M < 5 minutes. Je crois que 5 minutes est un temps garanti Azure Runtime attendra après qu'il a déclenché OnStop() et avant qu'il ne termine le processus.

J'imager quelque chose comme ceci:

public override void Run() { 
    // create a cancellation token source 
    try { 
    // pass the token to all processing/listening routines 
    } 
    catch (Exception e) { } 
} 

public override void OnStop() { 
    try { 
     // trigger the cancellation token source 
    } 
    catch (Exception e) { } 
} 

L'échantillon naïf ci-dessus suppose que toutes mes routines de traitement sont async haut en bas (aux appels EF/HttpClient). Si c'est le chemin à parcourir, j'ai besoin d'un exemple de travail qui prenne en charge les conditions préalables (hôte WCF, écouteurs de file d'attente).

Les questions ouvertes:

1. Comment puis-je faire une demande de TCP plus sûr entrants sont envoyés à mon rôle de travailleur après OnStop() est déclenché? Ceci est important pour adapter le code d'arrêt à une limite de 5 minutes.
2. Comment trouver des chiffres concrets pour N et M en tenant compte de tous les éléments comme les temporisations de canal WCF, les délais d'attente EF, etc. dans le fichier de configuration?
3. Sera-t-il encore possible pour le code synchrone?

Answer 1

Arrêtez l'acceptation de toutes les demandes entrantes une fois RoleEntryPoint.OnStop() est déclenchée. Est-ce que Azure le fait pour moi? Sinon, comment puis-je l'appliquer?

Comme ce document mentionné à propos ServiceHost.close() officiel:

La méthode Close permet des travaux non finis à remplir avant de retourner. Par exemple, terminez l'envoi des messages mis en mémoire tampon. Pour clôturer gracieusement le service WCF en recevant une nouvelle requête mais permettre aux connexions existantes de continuer, vous pouvez vous référer à issue.

Pour écouter les files d'attente Service Bus, vous pouvez définir un objet CancellationTokenSource et appeler CancellationTokenSource.Cancel() une fois que RoleEntryPoint.OnStop() est déclenché.

et vérifier si l'annulation a été demandée pour CancellationTokenSource comme suit:

try 
{ 
    if (!_cancellationTokenSource.IsCancellationRequested) 
    { 
     //retrieve and process the message 
    } 
} 
catch (Exception) 
{ 
    // Handle any message processing specific exceptions here 
} 

Allow N secondes pour une opération en attente pour compléter

par ma compréhension, je suppose que vous pourriez juste appelez Task.Delay(TimeSpan.FromSeconds(N)).Wait() après avoir appelé CancellationTokenSource.Cancel() et terminé le service WCF dans la fonction OnStop. Ensuite, les opérations en attente seront supprimées avec la fermeture de l'instance de rôle de travail. Comment trouver des nombres concrets pour N et M en tenant compte de tous les éléments tels que les temporisations des canaux WCF, les délais d'EF, etc. dans le fichier de configuration?

Je suppose que vous pourriez tirer parti Application Insights avec votre rôle de travail pour récupérer les données de mesures et configurer la valeur raisonnable pour N, afin de réduire le taux de demande a échoué et rapidement que votre redémarrage VM et de commencer le traitement des nouvelles demandes. Vous pouvez également vous référer à ce tutorial à propos de la gestion de l'événement Azure OnStop.