Konkurrierender Zugriff auf Log-Datei mit Log4J

[oltoko]

Hi,

weis jemand ob es eine möglichkeit gibt mit mehreren Instanzen von einem Programm, das Log4J nutzt, in die gleiche Log-Datei zu schreiben, ohne das dabei Logs durch das konkurrierende speichern verloren gehen? Vllt hatte jemand schon das Problem, oder weiß aus zufall jemand ob ich die Möglichkeit besitzte in log4j sowas zu konfigurieren?

Danke im Voraus

 

[FArt]

Gibt es meines Wissens noch nicht, aber eine Eigenimplementierung dürfte einfach sein: ein eigener Appender ist schnell geschrieben, die Schnittstelle ist recht trivial. Die Umsetzung mit dem java.nio package ist auch kein Hexenwerk... jetzt kommt es nur noch auf das Betriebsysstem an, ob es lockiing auf Files unterstützt... die meisten aktullen tun das aber...

 

[Siassei]

Wie sinnvoll eine derartige Implementation ist, ist fraglich? (Schöner Satz )
Log4J und alle mir bekannten Log-Systeme wurden für höchste Performance und Geschwindigkeit entworfen und gestaltet. Eine Zugriffskontrolle vermindert die Geschwindigkeit bei vielen Log-Anfragen sehr stark und ...

Viel Spaß bei der Entscheidung

 

[Gast]

wird man aber kaum drumherum kommen, wenn man "sicheres" logging braucht. so eklig es ist, der wrapper wird blockierend synchronisieren müssen.

 

[Siassei]

wird man aber kaum drumherum kommen, wenn man "sicheres" logging braucht. so eklig es ist, der wrapper wird blockierend synchronisieren müssen.

Kommt drauf an. Der OP erwähnte nicht, dass es sich um eine *.txt handeln muss. Wobei ich nicht den Sinn einer solchen Log-Strategie sehen kann. Vielleicht liegt es daran, dass ich Java nur als Hobby ansehe :wink:

Wie wär's mit einem Appender, der mittels JDBC oder ODBC auf eine DB zugreift? Hier erledigt die DB das Speichern und die App wird es kaum spüren. Man muss ja nicht gleich eine komplette DB im Hintergrund laufen lassen H2, MS Access, HSQL, ... gibt es doch auch und die Log-Daten sollten im nach hinein einfach auszulesen sein. Wer sagten den, dass zum lesen von Log-Dateien umbedingt ein Texteditor benutzt werden muss. Eine schöne Tabellenkalkulationliste (ich wollte nicht Exel sagen ) mit der ich sogar die Logdaten mit ein paar Klicks ordnen kann ist doch das schönste auf der Welt

 

[Gast]

kommt drauf an, welche aufgabe das logging erfüllen soll. das worst case szenario ist, dass die ganze vm absemmelt und die logs sind das einzige, was noch aufschluss über die ursache geben könnte. wenn die logs dann durch irgendeinen daemon asynchron in die db oder in ein file geschaufelt werden, könnten gerade die wichtigsten letzten bytes es nicht mehr ins log geschafft haben. nicht ohne grund verwenden viele logger nichteinmal nen buffer.

 

[FArt]

Na ja, die Frage ist ja nicht ob Logging allgemein sinnvoll ist oder nicht, sondern ob wirklich verschiedene Instanzen in ein Logfile schreiben wollen / sollen.

Meine Meinung dazu: in der Regel unnötig.

Wenn ich zeitliche Vergleiche brauche (sehr selten, eher nie), dann geht das auch nur verlässlich mit Prozessen auf einer Maschine, und dann merge ich die Logfiles über den Timestamp... aber bisher reichte auch in einer Clusterumgebung das Logfile einse Prozesses für sich bzw. die Logfiles der Prozesse parallel...

 

[Siassei]

Meine Meinung dazu: in der Regel unnötig.

Dem kann ich nur zustimmen :wink:

nicht ohne grund verwenden viele logger nichteinmal nen buffer.

Wer redet hier von einem Buffer? :wink:

 

[Guest]

nicht ohne grund verwenden viele logger nichteinmal nen buffer.

Wer redet hier von einem Buffer? :wink:

na du dein vorschlag hörte sich so an, als würdest du dem caller sofort wieder resourcen zusprechen wollen, bevor das log persistent gespeichert wurde.

 

[oltoko]

Hi,

erstmal danke für die vielen tollen Antworten!! Ich werde den Ansatz mit dem eigenen Appender, der ein "write lock" auf die Log-Datei legt jetzt mal verfolgen!! Ich werd ja dann sehen wieviel Zeit mich das tatsächlich kostet falls eine zweite Instanz auf die Sperre läuft und dann einfach mal kurz (oder auch länger) warten muss!!

Mfg oltoko

 

[FArt]

Vielleicht ist es auch viel praktikabler das ganze mit einem Server zu realisieren, nicht zuletzt weil hier die Appender schon fertig sind...

SocketAppender, JMSAppender... oder alles in eine Datenbank... JDBCAppender...

Schau doch einfach mal bei log4j rein, was es da so alles gibt.

 

[oltoko]

Vielleicht ist es auch viel praktikabler das ganze mit einem Server zu realisieren, nicht zuletzt weil hier die Appender schon fertig sind...

SocketAppender, JMSAppender... oder alles in eine Datenbank... JDBCAppender...

Schau doch einfach mal bei log4j rein, was es da so alles gibt.

Das hab ich schon, leider ist das alles nicht gewünscht :wink: !! Ich hätte es auch lieber so gemacht, da z.B. auch die Lösung mit syslog (SyslogAppender) das ganze Problem gelöst hätte!! Jedoch bin ich leider nur die Exekutive und nicht die Legislative !!