Wir haben eine Anwendung, die in mehreren Threads läuft und Log4Net als Logging-Framework verwendet. Wir haben ein Szenario gefunden, in dem einige Protokollereignisse nicht protokolliert wurden. Wie in den Dokumenten erwähnt, sind der FileAppender und die anderen Appender " nicht sicher für Multithread-Operationen ".
Ich suchte im Internet nach Lösungen oder Appenders, konnte aber keine finden.
Kennen Sie einen Multithread-sicheren Log4Net Appender, der einen Ringpuffer oder eine Warteschlange für Multithread-Unterstützung verwendet? Oder sollten wir überhaupt ein anderes Multithread-sicheres Logging-Framework verwenden?
Vielen Dank im Voraus!
Ich habe einige Komponententests geschrieben, um das Problem zu reproduzieren: Ein Test erstellt 50 Threads und jeder Thread protokolliert 500 Nachrichten. Danach wurden die geschriebenen Zeilen gezählt und als Ergebnis erhielt ich 25.000 (50 x 500) Zeilen in unterschiedlicher Reihenfolge. Ich habe es auf einem Dual Core und auf einer Acht-Kern-Maschine getestet.
Ich habe einen statischen Logger getestet:
und mit einem Logger für jede Instanz der Testklasse / des Threads:
%Vor%
Und alle Tests waren grün.
Log4Net funktioniert also gut und behandelt Multithreading-Szenarien gut. Die Appender-Dokumente sollten aktualisiert werden und angeben, dass Multithread-Operationen unterstützt werden, wenn die Logger-API auf die richtige Weise verwendet wird
Ich denke, das Problem mit fehlenden Protokolleinträgen, die wir auf dem Rechner eines Kunden vorfanden, ist auf andere Probleme zurückzuführen. Möglicherweise ist die zugrunde liegende VM oder Hardware defekt.
Danke für Ihre Hilfe!
Ich habe FileAppender nie benutzt und kann nicht sagen, ob es threadsicher ist, aber ich hatte nie Probleme mit RollingFileAppender . Die Dokumentation besagt, dass Mitglieder des Typs nicht threadsicher sind. Dies sollte jedoch OK sein, es sei denn, Sie versuchen, direkt in den Appender zu schreiben. Sie müssen Ihren eigenen Sperrcode nicht bei Anrufen wie:
hinzufügen %Vor%Dass die Tests grün sind, bedeutet nicht, dass die Zeilen tatsächlich in die Datei geschrieben wurden, aber dass es keine Ausnahme gab. Oder hast du die Prüfung eingeschlossen, die die Datei auch in deinem Test liest? Ich habe das gleiche Problem, nachdem ich Web-Gärten in IIS eingeschaltet. Zu diesem Zeitpunkt schrieb nur ein Thread Zeilen in die Datei.
Das Log4Net ist Thread-sicher, aber die verwendeten Appender können ein Problem sein. Die Dateiapplikatoren blockieren beim Aufruf "Block". Das bedeutet, dass in Ihrer Anwendung jedes an Log4Net gesendete Protokoll jeden Appender vervollständigen muss, bevor es zu Ihrer Anwendung zurückkehrt.
Es ist Thread-sicher, viele Threads können Log4Net verwenden, um Nachrichten zu protokollieren, aber wenn Log4Net aufgerufen wird, wartet die Anwendung darauf, dass die Appender abgeschlossen werden. Die Ausführungszeit der Protokollierung wird Ihrer Anwendungszeit hinzugefügt.
Das ist leicht zu beweisen. Siehe: Ссылка
Was ich getan habe, ist, die Log4Net-Funktionen in einem statischen Singleton zu "wickeln", das Thread-sicher ist, und dann jede Log-Nachricht in die Warteschlange zu stellen, die in einem gleichzeitigen Thread läuft. Dies führt dazu, dass die gesamte Protokollierung gleichzeitig mit der Anwendung erfolgt, die Anwendungsausführung jedoch nicht auf den Abschluss der Appender wartet.
Tags und Links .net c# multithreading logging log4net