Hallo Community,
ich habe einen Windows-Dienst erstellt, mit welchem ich Daten aus einer Datenbank auslese und diese per Mail versende.
Nun mein Problem: Wenn der Dienst startet wird ein neuer Thread erzeugt.
private Thread thread;
WorkDienste workDienste = new WorkDienste();
protected override void OnStart(string[] args)
{
thread = new Thread(new ThreadStart(workDienste.Begin));
thread.Start();
}
Innerhalb dieses Threads läuft das Auslesen der Daten usw. ab.
public void Begin()
{
[...]
WorkAuto(true);
}
public void WorkAuto(bool los)
{
[...]
while(los)
{
BReturn = true;
DoIt(); //führt das Auslesen und Versenden durch
Thread.Sleep(10000);
}
[...]
}
Nach einiger Zeit (ca. 6 Stunden) wird der Dienst zwar noch als laufend geführt, macht aber defacto nichts mehr.
Weiß jemand warum das so ist, bwz. wie ich dies verhindern kann?
Danke schonmal im Vorraus
MiVam
In 99% der Fälle sitzt der Fehler vor dem Gerät.
Bau einmal in deiner WorkAuto Methode oder nur um die DoIt Methode ein try-catch und behandle etwaige Fehler. Wenn ein Fehler in einem anderen Thread passiert, muss das nicht bedeuten, dass das Service deswegen beendet wird jedoch der Thread und die Schleife werden dadurch mit Sicherheit beendet sein.
Bau Logging ein und schau, ob das Program nach 6 Std. noch immer die Schleife sauber abarbeitet bzw. falls nicht, solltest du sehen bis wohin es zuletzt gekommen ist.
Lg, XXX
Hallo MiVam,
möglicherweise rennt dein Thread in eine Exception.
Ausserdem:
Benutze besser einen Timer, statt Thread.Sleep.
Gruß, Alf
Benutze besser einen Timer, statt Thread.Sleep.
Da es sich hier um einen Windows-Dienst handelt, ist das vorgehen schon richtig so. Mann muss aus dem OnStart raus, aber (mind.) einen Thread am Laufen haben, damit der Dienst nicht ausgeht.
Sind die 6 Stunden reproduzierbar? Irgendwelche Timeouts (Sessions, Transaktionen, etc.)?
Die sechs Stunden sind ziemlich genau reproduzierbar, wenn auch nicht genau auf die Minute. Das mit dem try-catch werd ich mal versuchen, mal sehen ob sich da was ergibt.
In 99% der Fälle sitzt der Fehler vor dem Gerät.
Guck doch mal in die Event Logs. Wenn ein .net Fehler aufgetreten ist sollte dieser dort drin stehen.
LG pdelvo
Hat jetzt etwas länger gedauert (Motherboard-Schaden), aber ich hab jetzt herausgefunden, dass die Connections zur Datenbank nicht mehr erstellt werden können. Ich hab auch schon nachgesehen, ob ich evtl. einzelne nicht wieder schließe, aber ich bin konsequent bei max. zwei offenen zur gleichen Zeit.
In 99% der Fälle sitzt der Fehler vor dem Gerät.
Hallo,
ich würde Dir empfehlen die Connection in einen using Block zu öffnen. Egal wie du diesen Block verlässt, die Connection wird auf alle fälle geschlossen.
Ich habe einen Windowsdienst der ständig mit einem SqlServer Verbindungen auf und abbaut.
Der läuft derzeit seit 7 Monaten , incl. SqlDependency usw.
Also an .NET selber sollte das da nicht liegen.
Kann es aber sein das du mal länger fürs aufbauen der Verbindung brauchst und da in einen Timeout gehst, der nicht vernünftig abgefangen ist?
Meine Connections sind schon in einem Using-Block. Ich überlege gerade, ob die Connection nicht ordentlich geschlossen wird, weil ja ein Dispose statt einem Close ausgeführt wird.
Ein unbemerktes Time-Out könnte sein, ich hab grade festgestellt, dass ich zwar alle Aufrufe meiner Connection-Klasse in ein Using einschließe, aber nur den Aufbau der Connection selber über ein try-catch mitlogge.
In 99% der Fälle sitzt der Fehler vor dem Gerät.
Das Dispose führt ein Close aus.
Die ham sich schon was gedacht, dass sie IDisposable implementieren und innerhalb eines usings
verfügbar machen.
Steht sogar mit ausführlicher Beschreibung und Beispielcode in der MSDN.
Trotzdem drehen wir uns hier im Kreis und wenn Du nicht jedes relevante Detail Deiner Anwendung / Deines Dienstes loggen willst, was Du solangsam tun solltest, dann ist das hier nur Zeitverschwendung und heiteres Glaskugel-Raten.
- performance is a feature -
Microsoft MVP - @Website - @AzureStuttgart - github.com/BenjaminAbt - Sustainable Code
Also als glaskugellesen kann ich das nicht bezeichnen, immerhin ist schonmal klar eingegrenzt, wo der Fehler liegt. Nur eben nicht, was genau der Fahler ist. Außerdem logge ich mittlerweile dermaßen viel mit, dass ich kurz davor bin in der entsprechenden Datei den Überblick zu verlieren, zumal der Verbindungsaufbau selbst ja schon immer geloggt wurde (da hatte ich eher Probleme vermutet).
In 99% der Fälle sitzt der Fehler vor dem Gerät.
Tja, dann bleibt Dir wohl nur noch Profiling a Windows Service that runs on startup
- performance is a feature -
Microsoft MVP - @Website - @AzureStuttgart - github.com/BenjaminAbt - Sustainable Code
Oder häng dich mit dem Visual Studio Debugger(notfalls Remotedebugger) ins Programm wenn es nicht mehr weiter tut und prüfe falls möglich den Zustand auf diese Weise.
Lg, XXX
//Edit: Übrigens könntest du dein Programm ja auch einfach als Konsolenanwendung oder gleich direkt im Debugger laufen lassen(falls VS am Zielrechner installiert ist) um es einfacher/anders zu testen.