Wie zu verwenden Threadpool.QueueUserWorkItem in einem windows-Dienst?

Ich habe einen windows-Dienst, wo ich mit Threadpool.QueueUserWorkItem. Der service verbindet, um mehrere client-Datenbanken, packt die Daten, konvertiert Sie in die Formate XLS und senden von Dateien an den entsprechenden FTP.

Ich habe 3 Fragen bezüglich des Kodex unter:

  1. Bin ich mit dem Threadpool.QueueUserWorkItem richtig?
  2. Brauche ich Schloss irgendwo in den code, um Probleme zu vermeiden? Wenn ja, wo und zu welchem Zweck.
  3. Gibt es etwas, das nicht korrekt in den code? Wenn ja, was und wie mit Ihr umgehen?

Code:

private static System.Timers.Timer aTimer = new System.Timers.Timer(50000);

public void OnStart(string[] args)
        {
            CLE.WriteToEventLog("Service Started");
            try
            {
                aTimer.Elapsed += new ElapsedEventHandler(PerformTimerOperation);
                aTimer.Enabled = true;
            }
            catch (Exception ex)
            {
                CLE.WriteToEventLog("Error Starting Service: " + ex.Message);
            }
        }

private void PerformTimerOperation(object source, ElapsedEventArgs e)
        {
            CLE.WriteToEventLog("Timer Operation Started");
                Clients objClient = new Clients();
                List<Clients> objClientList = Clients.GetClientList();

                foreach (var list in objClientList)
                {
                    ThreadPool.QueueUserWorkItem(new WaitCallback(SendFilesToClient), list);
                }                
        }

private void SendFilesToClient(Object stateInfo)
        {
            CLE.WriteToEventLog("Send Files To Client Started");
            Clients oClient = (Clients)stateInfo;
            CLE.WriteToEventLog("Start Proecessing Client: " + oClient.ClientName + ", ClientId: " + oClient.ClientId);

            connectionString = App.Database.PrimaryConnectionString(oClient.ClientId);

            string reports = oClient.Reports;
            string[] values = reports.Split(',').Select(sValue => sValue.Trim()).ToArray();

            foreach (string item in values)
            {
    //Send data to FTP based on cliend id
            }
            //At this point all reports are being sent to the FTP. We will update the database with LastExecutionDateTime + 1 hour. This will be used as DateFrom param for all reports for the next execution.
        }

Der service funktioniert einwandfrei und ich bekomme die entsprechenden Ergebnisse, aber ich brauche zu machen sicher, ich mache es richtig und nicht in die Fragen später.

  • Nur hat das @Grau. Es ist C# .NET 4.0
  • Das sieht fein zu mich. Bezüglich Ihrer Frage #2, sollte es keine Notwendigkeit für sperren, da Ihre threads laufen völlig unabhängig voneinander. Die Schleusen sind notwendig, wenn Sie die Koordinierung des Zugriffs auf eine gemeinsame Ressource, aber in diesem Fall ist jeder worker-thread hat seine eigene Datenbank und arbeitet auf einem Satz von "Zeug".
  • Danke @GalacticCowboy!
InformationsquelleAutor Learner | 2013-02-26
  1. 5

    Ich bin vorausgesetzt, Ihr service soll weiter laufen im Gegensatz zu "one-and-done". Wenn dem so ist, bitte beachten Sie, dass die AutoReset Eigenschaft des System.Timers.Timer Klasse ist auf true standardmäßig. Dies bedeutet einfach, dass der timer weiter zu erhöhen, die Elapsed Ereignis jedes mal die 50-Sekunden-Intervall verstreicht (50000 Millisekunden = 50 Sekunden). Wenn Sie wissen, sicher, dass alle SendFilesToClient Vorgänge rechtzeitig vor dem nächsten Intervall verstreicht, dann sollten Sie ok sein. Allerdings würde ich nicht darauf Wetten. Was ist, wenn sich die Datenbank auf dem Netzwerk und das Netzwerk ausfällt? Was ist, wenn der Dienst ausgeführt wird, auf einem langsameren system oder eins mit weniger Kernen und all die Arbeit ist nicht abgeschlossen in der Zeit?

    Sie könnten dies umgehen, indem Sie das AutoReset feature so gerne.

    private static var aTimer = new System.Timers.Timer(50000) { AutoReset = false };

    Dies bedeutet, dass die Elapsed - Ereignis wird nur ausgelöst, sobald. Innerhalb der PerformTimerOperation einfach rücksetzen der Enabled Eigenschaft true den timer neu starten, bevor Sie verschwinden.

    Aber dies ist eine unvollständige Lösung, da die Gewinde immer noch zu lange dauern, um abzuschließen, bevor der timer löst Elapsed Veranstaltung. In diesem Fall möchten Sie vielleicht die Verwendung einer ManualResetEvent zu signalisieren, wenn jeder thread abgeschlossen ist, und unterbrechen beenden PerformTimerOperation (und der timer zurückgesetzt), bis das Auftritt. Zum Beispiel,

    private void PerformTimerOperation(object source, ElapsedEventArgs e)
{
    List<Clients> objClientList = new Clients().GetClientList();
    List<ManualResetEvent> handles = new List<ManualResetEvent();

    foreach (var list in objClientList)
    {
        //Create an MRE for each thread.
        var handle = ManualResetEvent(false);

        //Store it for use below.
        handles.Add(handle);

        //Notice two things:
        //1.  Using new WaitCallback(...) syntax is not necessary.
        //2.  Thread argument is now a Tuple object.
        ThreadPool.QueueUserWorkItem(SendFilesToClient, Tuple.Create(list, handle));
    }

    //Wait for threads to finish.
    WaitHandle.WaitAll(handles.ToArray());

    //Reset the timer.
    aTimer.Enabled = true;
}

    Nun update SendFilesToClient.

    private void SendFilesToClient(Object stateInfo)
{
    //The parameter is now a Tuple<T1, T2>, not a Clients object.
    var tuple = (Tuple<Clients, ManualResetEvent>)stateInfo;

    try
    {
        Clients oClient = tuple.Item1;

        //Do your work here...
    }
    catch (Exception ex)
    {
        //Handle any exception here.
    }
    finally
    {
        //Signal that the work is done...even if an exception occurred.
        //Otherwise, PerformTimerOperation() will block forever.
        ManualResetEvent mreEvent = tuple.Item2;
        mreEvent.Set();
    }
}

    In diesem Mode, der PerformTimerOperation wird der block auf die WaitHandle.WaitAll() aufrufen, bis alle worker-threads, z.B. SendFilesToClient, signalisieren, dass Sie fertig sind. An diesem Punkt, Sie die Stoppuhr zurücksetzen und wiederholen Sie den Vorgang mit dem nächsten Intervall.

    Sorry das ist so lange. Hoffe, es hilft.

    • Überhaupt nicht @Matt. Dieser ist eine wunderbare Erklärung. Auch, nur zur info, dieser Dienst muss laufen, jeder 1 Stunde, um das senden von Dateien auf den FTP. Also ich sehe kein problem mit dem Dienst ab, führen Sie vor Abschluss der vorherigen Aufgabe. Nicht, dass das einen Unterschied machen? Soll ich noch gehen, für Ihre Lösung (Umsetzung der AutoReset und ManualReset) als best practice? Jede Eingabe zu sperren? Danke!
    • Lassen Sie uns sagen, dass die Vorherige Aufgabe noch arbeitet, und eine neue task gestartet. Sind Sie beim öffnen der Datenbank-verbindungen? Möglicherweise gibt es ein limit, wie viele gleichzeitige verbindungen, die Sie geöffnet haben kann. Was ist mit dem Empfänger? Wenn Sie Dateien von der zweiten Aufgabe, vor der ersten Aufgabe, ist das ein problem? Die Wahrscheinlichkeit, dass Ereignisse wie diese mag klein sein, aber ein robustes system beschäftigt sich mit solchen Fragen. Sie kennen Ihr system besser als ich, also nutzen Sie Ihre engineering-Urteil. Wenn die PerformTimerOperation dauert normalerweise nicht länger als ein paar Minuten, ich vermute, du bist ok.
    InformationsquelleAutor Matt Davis
Schreibe einen Kommentar