Läuft eine lang andauernde Aufgaben in einem Windows-Dienst

Ich geschrieben habe, ein Windows-Dienst-Projekt, beherbergt eine lang andauernde Nachrichtensystem Aufgabe, die gemeint ist, für die Dauer des service. Wenn der Dienst gestartet wird, startet die task. Wenn der Dienst beendet, Stoppt er die Aufgabe:

void OnStart()
{
    MessagePump.Start();
}

void OnStop()
{
    MessagePump.Stop();
}

Wo MessagePump.Beginnen tut eine Aufgabe.Factory.StartNew und MessagePump.Stop-Signale die Aufgabe zu beenden und nicht Warten().

So weit So gut, aber ich Frage mich, wie man am besten auf Störungen reagiert. Wenn für die Aufgabe eine nicht behandelte Ausnahme, möchte ich den Dienst beenden, aber da ist nichts in der Regel Warten auf die Aufgabe, ich vorstellen, es werde einfach nur sitzen, nichts zu tun. Wie kann ich elegant mit dieser situation umzugehen?

UPDATE:

Der Konsens scheint zu sein, mit 'warten' oder ContinueWith. Hier ist, wie ich derzeit bin-Codierung meine Start-Methode zu verwenden:

public async static void Start()
{
    this.state = MessagePumpState.Running;
    this.task = Task.Factory.StartNew(() => this.ProcessLoop(), TaskCreationOptions.LongRunning);
    try
    {
        await this.task;
    }
    catch
    {
        this.state = MessagePumpState.Faulted;
        throw;
    }
}
  • Ich schlage vor, Sie verwenden async/await-mit rücktrittsmöglichkeit. Wann haben Sie das unbehandelte Ausnahme machen Stornierung-Programm wird wissen über den Fehler
  • Kann ich innerhalb eines Windows-Dienstes? Mein Verständnis ist, dass wenn ich ein await in OnStart() dann werde es nicht beenden, bis der Vorgang abgeschlossen? (könnte falsch sein)
  • Hmm. Was nicht erwartet Aufgabe auf MessagePump.Start()? Überprüfen Sie in diesem blog, können Sie finden, was Sie suchen. blog.stephencleary.com
InformationsquelleAutor Barguast | 2014-09-19
  1. 2

    Machen Sie MessagePump.Start () - Methode zurückgeben der Aufgabe. Dann 

    MessagePump.Start().ContinueWith(t => 
{
    //handle exception 
}, 
TaskContinuationOptions.OnlyOnFaulted);

    UPDATE:
    Ich würde den nächsten:

    private MessagePump _messagePump;

async void OnStart()
{
    this._messagePump = new MessagePump();
    try
    {
        //make Start method return the task to be able to handle bubbling exception here
        await _messagePump.Start();
    }
    catch (Exception ex)
    {
        //log exception
        //abort service
    }
}

void OnStop()
{
    _messagePump.Stop();
}

public enum MessagePumpState
{
    Running,
    Faulted
}

public class MessagePump
{
    private CancellationTokenSource _cancallationTokenSrc;
    private MessagePumpState _state;
    public async Task Start()
    {
        if (_cancallationTokenSrc != null)
        {
            throw new InvalidOperationException("Task is already running!");
        }

        this._state = MessagePumpState.Running;
        _cancallationTokenSrc = new CancellationTokenSource();
        var task = Task.Factory.StartNew(() => this.ProcessLoop(_cancallationTokenSrc.Token), _cancallationTokenSrc.Token);
        try
        {
            await task;
        }
        catch
        {
            this._state = MessagePumpState.Faulted;
            throw;
        }
    }

    public void Stop()
    {
        if (_cancallationTokenSrc != null)
        {
            _cancallationTokenSrc.Cancel();
            _cancallationTokenSrc = null;
        }
    }

    public void ProcessLoop(CancellationToken token)
    {
        //check if task has been canceled
        while (!token.IsCancellationRequested)
        {
            Console.WriteLine(DateTime.Now);
            Thread.Sleep(1000);
        }
    }
}
    • Oder verwenden Sie Sie erwarten. _
    • Vermutlich, wenn ich erwarten, die Ausführung von code würde vermutlich sitzen da und warten auf den task zu beenden, ohne OnStart?
    • wickeln Sie diese Logik in einer async-Methode, verwenden Sie es erwarten, und entsorgen Sie die Aufgabe, das async-Methode zurück. So dass Sie nicht haben, um mit fiesen Fortsetzungen und das Programm läuft weiter.
    • Nein, erwarten Sie nicht blockieren den aufrufenden thread. Es ist genau das gleiche (fast) wie ContinueWith.
    • Danke, das ist hilfreich. Ich habe aktualisiert mein Erster post mit einem Beispiel von dem, was meine Start-Methode sieht nun wie. Es nutzt erwarten und ein exception-handler (nur um einen member-Bereich) und scheint zu funktionieren, wie ich es erwartet habe. Es ist ein 'async void' - aber das scheint ein wenig seltsam, macht aber mehr Sinn, dass wieder eine Aufgabe (und vermeidet eine compiler-Warnung). Wenn es nicht zu viel verlangt, könnten Sie ihm einen Blick zu sehen, wenn ich mache etwas falsch?
    • wickeln Sie den code in eine asynchrone Aufgabe entledigen und die daraus resultierende Aufgabe. Fügen Sie ein code-Kommentar. Async void interagiert mit dem sync-Rahmen in einer Weise, die Sie wahrscheinlich nicht wollen (oder zu verstehen).
    • Sie sollten es vermeiden, async void-Methoden. Look at diesem Artikel
    • Wenn ich es ändern zu 'async-Task', die Störungen gehen wieder ignoriert (weil, wieder, ich habe eine Aufgabe, die niemand wartet auf). Ich denke, der beste Ansatz ist die Verwendung von await (in Start) und wickeln Sie es in ein try / catch. In meinen Fängen, rufen ein Ereignis (wie bei Sasha ' s Antwort) und mit der Beendigung meines Dienstes in einer Ereignisprozedur? Dann sollte ich nicht brauchen, um über sich auf eine nicht behandelte Ausnahme in der Nähe mein service (das scheint vorzuziehen)
    • meist wir sollten es vermeiden, async void-Methoden, aber in diesem Fall ok ist. Wie für Veranstaltungen - Feuer-und-Vergessen. Hier ist es das gleiche - keine Notwendigkeit zu warten, ein Ergebnis dieser Methode.
    • Danke. Ich kann nicht sagen, ich bin ganz sicher, die Gründe, warum ein void-Rückgabe problematisch ist in diesem besonderen Umstand, aber Ihre neuesten edit-sieht sehr hilfreich. Markiert als Antwort.

    InformationsquelleAutor sedovav
  2. 1

    Können Sie versuchen, so etwas wie dieses :

    void OnStart()
{
    MessagePump.StartAsync(); 
    MessagePump.ErrorEvent += OnError();
}

    Dann Ihre StartAsync wird etwa so Aussehen:

    public async Task StartAsync()
{
     //your process
     //if error, send event to messagePump
}

    Und wenn Sie sich entscheiden, verwenden Sie Aufgaben, dann ist es besser, verwenden Sie den Task.Laufen und nicht Aufgabe.Factory.StartNew()

    • Danke. Ich habe einen 'Fehlerhaften' - Ereignis ist für meine Klasse, das scheint zu sein, wie die Dinge wie ServiceHost damit umgehen. Dein letzter Satz war auch interessant - ich dachte, Aufgabe.Laufen war im Grunde das gleiche wie Aufgabe.Factory.StartNew aber minus, einige der komplexen Optionen. Ich denke, ich sollte die Einstellung LongRunning auf meine Aufgabe zumindest. Nicht sicher, ob es irgendwelche anderen Vorteile zu Aufgabe.Laufen?
    • haben Sie einen Blick auf diesen Artikel blogs.msdn.com/b/pfxteam/archive/2011/10/24/10229468.aspx
    InformationsquelleAutor Sasha
Schreibe einen Kommentar