Comment arrêter correctement un multi-threaded.NET service windows?

Le gestionnaire de contrôle de service (SCM) retournera lorsque vous revenez de OnStop. Vous devez donc réparer votre implémentation OnStop pour bloquer jusqu'à ce que tous les threads soient terminés.

L'approche générale consiste à faire en sorte que tous vos threads s'arrêtent, puis à attendre qu'ils s'arrêtent. Pour éviter de bloquer indéfiniment, vous pouvez donner aux threads une limite de temps pour les arrêter, puis les abandonner s'ils prennent trop de temps.

Voici ce que j'ai fait dans le passé:

1. créer un indicateur bool global appelé Stop, défini sur false lorsque le service est démarré.
2. lorsque la méthode OnStop est appelée, définissez L'indicateur Stop sur true, puis faites un Thread.Rejoignez sur tous les threads de travail.
3. chaque thread de travail est responsable de la vérification de L'indicateur D'arrêt et de la sortie proprement quand elle est vraie. Cette vérification doit être effectuée fréquemment, et toujours avant une opération de longue durée, pour éviter qu'elle ne retarde trop longtemps l'arrêt du service.
4. dans la méthode OnStop, ayez également un délai d'attente sur la jointure appels, pour donner aux threads un temps limité pour quitter proprement... après qui vous vient de l'abandonner.

Note dans #4, vous devriez donner suffisamment de temps pour que vos threads sortent dans le cas normal. L'abandon ne devrait se produire que dans un cas inhabituel où le fil est suspendu... dans ce cas, faire un abandon n'est pas pire que si l'utilisateur ou le système tue le processus (ce dernier si l'ordinateur s'arrête).

La façon simple de le faire peut ressembler à ceci:
- première Crète un événement mondial

ManualResetEvent shutdownEvent;

- au démarrage du service, créez l'événement de réinitialisation manuelle et définissez-le sur un état initial de non signalé

shutdownEvent = new ManualResetEvent(false);

- à l'événement d'arrêt de service

shutdownEvent.Set();

n'oubliez pas d'attendre la fin des threads

do
{
 //send message for Service Manager to get more time
 //control how long you wait for threads stop
}
while ( not_all_threads_stopped );

- chaque thread doit tester de temps en temps, l'événement à arrêter

if ( shutdownEvent.WaitOne(delay, true) ) break;

Signalez la sortie de la boucle de vos threads, nettoyez-la et faites thread Join-S.. recherchez combien de temps cela prend comme mesure/chronomètre où les problèmes sont. Évitez l'arrêt avorté pour diverses raisons..

Pour répondre à la première question (Pourquoi le service continuerait-il à fonctionner pendant plus de 30 secondes): il existe de nombreuses raisons. Par exemple, lors de l'utilisation de WCF, l'arrêt d'un hôte provoque l'arrêt du processus d'accepter les demandes entrantes, et il attend de traiter toutes les demandes en cours avant de s'arrêter.

La même chose serait vraie pour les autres types d'opérations réseau: les opérations tenteraient de se terminer avant de se terminer. C'est pourquoi la plupart des requêtes réseau ont une valeur de délai d'attente intégrée pour quand la requête peut avoir "accroché" (serveur tombé en panne, problèmes réseau, etc.).

Sans plus d'informations sur ce que vous faites exactement, il n'y a pas moyen de vous dire spécifiquement pourquoi cela prend 30 secondes, mais c'est probablement un délai d'attente.

Pour répondre à la deuxième question (Pourquoi le contrôleur de service revient-il): Je ne suis pas sûr. Je sais que la classe ServiceController a une méthode WaitForState qui vous permet d'attendre jusqu'à ce que l'état donné soit atteint. Il est possible que le service le contrôleur attend un temps prédéterminé (un autre délai), puis met fin de force à votre application.

, Il est également très possible que la base.La méthode OnStop a été appelée, et la méthode OnStop est retournée, signalant au ServiceController que le processus s'est arrêté, alors qu'en fait il y a des threads qui ne se sont pas arrêtés. vous êtes responsable de termingating ces fils.

Pour les personnes qui cherchent, comme moi, une solution pour raccourcir le temps de fermeture, essayez de définir le CloseTimeout de votre ServiceHost.

Maintenant, j'essaie de comprendre pourquoi il faut tellement de temps pour s'arrêter sans elle et je pense aussi que c'est un problème de threads. J'ai regardé dans Visual Studio, en m'attachant au service et en l'arrêtant : j'ai des threads lancés par mon service qui sont toujours en cours d'exécution.

Maintenant, la question Est : est-ce vraiment ces threads qui font que mon service s'arrête si lentement ? N'a pas Microsoft pense à ce sujet ? Ne pensez-vous pas que cela peut être un problème de libération de port ou autre chose ? Parce que c'est une perte de temps de gérer les threads sto et finalement ne pas avoir un temps de fermeture plus court.

Matt Davis est assez complet.
Quelques points; Si vous avez un thread qui s'exécute pour toujours (parce qu'il a une boucle presque infinie et un catch all) et que le travail de votre service est d'exécuter ce thread, vous voulez probablement que ce soit un thread de premier plan.

En outre, si l'une de vos tâches effectue une opération plus longue telle qu'un appel sproc et que votre délai D'attente de jointure doit être un peu plus long, vous pouvez demander au SCM plus de temps pour arrêter. Voir: https://msdn.microsoft.com/en-us/library/system.serviceprocess.servicebase.requestadditionaltime(v=vs. 110).aspx Cela peut être utile pour éviter le statut redouté "marqué pour la suppression". Le maximum est défini dans le registre, donc je demande généralement le temps maximum attendu dans lequel le thread s'arrête habituellement (et jamais plus de 12s). Voir: Quelle est la durée maximale d'attente du service windows pour traiter la demande d'arrêt et comment demander du temps supplémentaire

Mon code ressemble à quelque chose comme:

private Thread _worker;       
private readonly CancellationTokenSource _cts = new CancellationTokenSource(); 

protected override void OnStart(string[] args)
{
    _worker = new Thread(() => ProcessBatch(_cts.Token));
    _worker.Start();             
}

protected override void OnStop()
{            
    RequestAdditionalTime(4000);
    _cts.Cancel();            
    if(_worker != null && _worker.IsAlive)
        if(!_worker.Join(3000))
            _worker.Abort(); 
}

private void ProcessBatch(CancellationToken cancelToken)
{
   while (true)
   {
       try
       {
           if(cancelToken.IsCancellationRequested)
                return;               
           // Do work
           if(cancelToken.IsCancellationRequested)
                return;
           // Do more work
           if(cancelToken.IsCancellationRequested)
                return;
           // Do even more work
       }
       catch(Exception ex)
       {
           // Log it
       }
   }
}