2010-09-09 2 views
13

Wir migrieren Logbuch von Log4j für mehrere Web-Anwendungen. Bei der Abschaltung unserer Anwendung nennen wir zur Zeit:Muss ich Ereignisse beim Herunterfahren mit Logback leeren?

org.apache.log4j.LogManager.shutdown(); 

, die angeblich alle asynchrones Logging spülen und schließen Sie alle externen Ressourcen (Dateien, Sockets).

Gibt es etwas Ähnliches im Logback oder wird es beim Herunterfahren automatisch gespült?

Mike

+0

Interessante Frage - ich würde nie wirklich dachte darüber nach. Da Sie log4j explizit für die Pufferausgabe konfigurieren müssen, wäre ich davon ausgegangen, dass das Herunterfahren nur in diesem Fall aufgerufen werden muss. Ich glaube, dass slf4j standardmäßig gepuffert ist. –

+2

Logback flushes nach jeder Log-Anweisung, so dass es keinen expliziten stop() -Aufruf gibt, es sei denn, Sie tun etwas Funky. –

+2

@DavidRoussel Diese Aussage brachte mich dazu, [Logback Appenders] (http://logback.qos.ch/manual/appenders.html) nachzuschlagen. In der Tat: Standardmäßig wird jedes Log-Ereignis sofort in den zugrunde liegenden Output-Stream geleert. Dieser Standardansatz ist sicherer in dem Sinne, dass Protokollierungsereignisse nicht verloren gehen, wenn Ihre Anwendung beendet wird, ohne die Appender ordnungsgemäß zu schließen. Um jedoch den Protokollierungsdurchsatz erheblich zu erhöhen, empfiehlt es sich, die Eigenschaft sofortFlush des zugrunde liegenden Encoders auf false zu setzen. Encoder und insbesondere LayoutWrappingEncoder werden in einem separaten Kapitel beschrieben. _ –

Antwort

0

Ich bin mir nicht bewusst ein Gesamt Manager Shutdown wie log4j ist aber schließe ich alle meine individuellen Kontext Loggern, wenn ihr Kontext wie so ein ServletContextListener zerstört wird unter Verwendung von:

ContextSelector selector = StaticLoggerBinder.getSingleton().getContextSelector(); 
LoggerContext context = selector.detachLoggerContext(contextName); 
if (context != null) { 
    Logger logger = context.getLogger(Logger.ROOT_LOGGER_NAME); 
    context.reset(); 
} else { 
    System.err.printf("No context named %s was found", contextName); 
} 

Auch LoggerContext .stop() ist verfügbar und tut einige der gleichen Funktionen intern, aber ich benutze es nicht, so kann ich nicht kommentieren, ob es besser ist als zurückgesetzt oder nicht.

7

Hier ist ein einfacher Ansatz:

import org.slf4j.ILoggerFactory; 
import org.slf4j.Logger; 
import org.slf4j.LoggerFactory; 

import ch.qos.logback.classic.LoggerContext; 

... 

ILoggerFactory loggerFactory = LoggerFactory.getILoggerFactory(); 
// Check for logback implementation of slf4j 
if (loggerFactory instanceof LoggerContext) { 
    LoggerContext context = (LoggerContext) loggerFactory; 
    context.stop(); 
} 
7

Es soll, dass nur das Hinzufügen <shutdownHook/> in Konfiguration scheint den Kontext zu stoppen.

Von logback docs:

<configuration> 
    <!-- in the absence of the class attribute, assume 
    ch.qos.logback.core.hook.DelayingShutdownHook --> 
    <shutdownHook/> 
    .... 
</configuration> 

Und von DelayingShutdownHook summary:

ShutdownHook Implementierung, die den Logback Kontext nach einer bestimmten Verzögerung stoppt. Die Standardverzögerung ist 0 ms (Null).