Log4j interrompe improvvisamente la registrazione

Question

Realizzo un'applicazione Portlet distribuita su un WebSphere Portal Server in esecuzione su Linux. Ogni portlet GUERRA utilizza Log4j per l'accesso con una configurazione di questo tipo, avendo ogni guerra due file di log:

log4j.logger.im.the.package=DEBUG, InfoAppender, DebugAppender 

log4j.appender.InfoAppender=org.apache.log4j.RollingFileAppender 
log4j.appender.InfoAppender.Threshold=INFO 
log4j.appender.InfoAppender.File=/tmp/infoWARName.log 
log4j.appender.InfoAppender.layout=org.apache.log4j.PatternLayout 
log4j.appender.InfoAppender.layout.ConversionPattern=%d %p [%c] - %m%n 

log4j.appender.DebugAppender=org.apache.log4j.RollingFileAppender 
log4j.appender.DebugAppender.Threshold=DEBUG 
log4j.appender.DebugAppender.File=/tmp/debugWARName.log 
log4j.appender.DebugAppender.layout=org.apache.log4j.PatternLayout 
log4j.appender.DebugAppender.layout.ConversionPattern=%d %p [%c] - %m%n 

Dopo la distribuzione, tutto funziona come fascino e file di log hanno iniziato a riempire. Dopo alcune ore e allo stesso tempo, la registrazione si interrompe e info.log e debug.log non vengono affatto aggiornati. È necessario ridistribuire la GUAR portlet nel server per riavviare la registrazione.

Qualche idea?

Aggiornamento:

Sto iniziando a sospettare ha a che fare con i miei VASI registrazione. Attualmente, questo è il JAR del dentro la mia cartella WEB-INF/lib:

com.springsource.org.apache.commons.logging-1.1.1.jar 
com.springsource.org.apache.log4j-1.2.15.jar 
com.springsource.slf4j.api-1.5.6.jar 
slf4j-log4j12-1.5.6.jar 

secondo aggiornamento:

Al ore dalla bontà alla fine, questo è il modo in Log4j è configurato in ogni applicazione Portlet. Ecco web.xml:

<context-param> 
    <param-name>log4jConfigLocation</param-name> 
    <param-value>classpath:miAppLog4j.properties</param-value> 
</context-param> 
<listener> 
    <listener-class>org.springframework.web.util.Log4jConfigListener</listener-class> 
</listener> 

E miAppLog4j.properties file si trova nella cartella esterna alla guerra e al Portale. Lo abbiamo reso disponibile in Portlet Classpath tramite Shared Library in WebSphere Portal.

Answer 1

Vorrei provare a spostare il percorso del file di registro in un punto diverso dal file system temporaneo.

Answer 2

Penso che il problema sia che si scrivono più WAR nello stesso file di registro. Nella nostra esperienza, log4j non può farlo in modo affidabile, in particolare con le appendici a rotazione. Quando si va a rotolare, gli altri sono confusi e incapaci di accedere ulteriormente. O continuare a accedere al vecchio file.

Ho il sospetto che si debba avere ogni registro WAR in un file diverso.

Answer 3

Hai fornito alcune informazioni di base, in modo da poter abbozzare solo alcune cause candidati e probabilità:

1. Problema con blocchi di file/maniglie/IO flusso

• Triggerred dal registro rotolamento?

  Negativo nel tuo caso. I tuoi due file di registro separati (informazioni e debug) si fermano allo stesso tempo per ogni WAR. Ogni file scorre alla dimensione massima predefinita (10 MB). È molto improbabile che entrambi i registri rotolino sempre nello stesso momento. L'errore non deve essere attivato dal log rolling. Conferma aggiuntiva configurando log4j.appender.InfoAppender.MaxFileSize=200MB

• Triggerrato dagli utenti che manipolano file Linux?

  Negativo nel tuo caso. È possibile che utenti/sysadmin che manipolano file possano creare blocchi o handle di file obsoleti. Linux non dovrebbe mai avere problemi con un utente coda -ing un file (ma Windows fa). Linux può avere problemi con gli utenti che zippano o modificano i file.Ma il tuo problema sembra molto ripetibile, rendendo improbabile questo a meno che tu non abbia automatizzato gli script che manipolano i file di log.

• Triggerrato dalle impostazioni di configurazione "competitive" in Websphere o Spring, con l'uso duplicato degli stessi file di registro da parte del server/framework?

  Sembra improbabile nel tuo caso. Sembra che tu non abbia impostato la configurazione di logging di Websphere commons. registrazione Commons è automaticamente incluso nel ClassLoader genitore server WebSphere e può essere configurato per "avvolgere" per Log4J configurando:

  File commons-logging.properties

  # Set application classloader mode as PARENT_LAST when deploying in WAS as .ear 
  priority=1 
  org.apache.commons.logging.LogFactory=org.apache.commons.logging.impl.LogFactoryImpl 
  

• innescata da problemi hardware/disco fallimento?

  ??? Sembra strano che un tale problema sarebbe molto ripetibile.

2. Problemi con i thread java?

• filo morte o deadlock

• massiccia thread di elaborazione/contesa in codice "altro", in modo che il codice con la registrazione non viene eseguito

  Dalla tua descrizione, presumo che l'applicazione è ancora in esecuzione e funziona bene con prestazioni e funzionalità normali, ma i log non sono scritti. Puoi confermare? In tal caso, non si tratta di un problema di thread con i thread webapp.

  Inoltre posso confermare che non è un problema filo nella logica Log4J, perché l'unica volta crea/utilizza il proprio filo è quando una delle AsynchAppender/ExternallyRolledFileAppender/SocketAppender/TelnetAppender è utilizzato o durante PropertyConfigurator.configureAndWatch o viene chiamato il metodo DOMConfigurator.configureAndWatch.

  , ovvero negativo.

3. Modifiche alle classi Log4J in ClassLoader, con l'utilizzo di configurazione differente?

• scontri Parent ClassLoader con Webapp ClassLoader

  Ad es Le tue webapp iniziano inizialmente con le tue classi configurate dalla directory WEBINF e tutto va bene, ma dopo un po 'di tempo un'app diversa causa (o uno degli strumenti di amministrazione del server del portale) causa il caricamento di una classe di conflitto nel genitore ClassLoader e nella tua app "raccoglie" questa nuova versione illegale della classe e fallisce.

  Molto probabilmente un problema: migliaia di utenti su Google hanno faticato con i caricatori di classe Websphere.

Azione suggerita:

• Assicuriamo tutte le tue applicazioni web utilizzano PARENT_LAST classloading - per accedere alla console di amministrazione e garantire che essi abbiano PARENT_LAST situato all'interno di tutte le configurazioni WebApp

• garantire sei ricevere i messaggi di errore interni di Log4J scritti sulla console Es. Prova deliberatamente eliminando forzatamente il log degli errori come amministratore mentre l'app è in esecuzione, creando un handle obsoleto. Se "Log4J:" i messaggi di errore non compaiono in console, allora questo è un problema serio.
  La prossima volta che si verifica il problema, intercettare eventuali messaggi di console di questo tipo e segnalarli. Inoltre, puoi impostare "-D log4j.debug" all'avvio di JVM/websphere, per scoprire esattamente cosa stava facendo Log4J prima/durante il problema - i messaggi andranno alla console.

• è davvero necessario impostare il livello di registrazione su DEBUG per tutti i pacchetti delle classi &? È meglio impostare INFO o WARN e impostare solo selettivamente quando si esegue il debug di problemi specifici?

Questo è un sacco di testo .......... B ^)

Answer 4

Per oltre 5 anni, Log4j ha quasi nessun bug corretti: si tratta di un progetto in modo efficace morto. Se accettabile, prendere in considerazione la sostituzione con Logback, che implementa direttamente SLF4j.

Logback e SLF4J sono scritti dallo stesso ragazzo che ha scritto Log4J (Ceki), ha una licenza ancora più liberale e ha una buona comunità. È il successore di Log4J 1 in ogni modo possibile (tranne che per il suo nome).

Answer 5

Non sono sicuro del motivo per cui log4j si sta arrestando nell'applicazione. Ma potresti (dovresti) aggiornare a log4j 2.0. Il passaggio non dovrebbe essere molto impegnativo. È necessario riscrivere il file log4j.properties in un file XML perché la nuova versione non supporta più il file delle proprietà.

Nel Java Magazin un articolo afferma che log4j 2.0 si sta comportando in modo più affidabile in ambienti con multithreading, quindi c'è una possibilità che risolverà il problema. In caso contrario, hai ancora il vantaggio della nuova versione.

Porta delle belle caratteristiche e miglioramenti (copiati dal sito log4j):

API Separazione

L'API per Log4j è separata dalla realizzazione chiarendo agli sviluppatori quali classi e modalità di applicazione possono usare assicurando la compatibilità diretta. Ciò consente al team Log4j di migliorare l'implementazione in modo sicuro e compatibile.

prestazioni migliorate

Log4j 2 esegue più veloce di Log4j 1.x in aree critiche e in modo simile a logback nella maggior parte delle circostanze. Vedi Prestazioni per maggiori informazioni. Supporto per più API Mentre l'API Log4j 2 fornisce le migliori prestazioni, Log4j 2 fornisce il supporto per le API SLF4J e Commons Logging.

di caricamento automatico di configurazioni

Come Logback, Log4j 2 può ricaricare automaticamente la propria configurazione in caso di modifica. A differenza di Logback, lo farà senza perdere gli eventi di registro mentre è in corso la riconfigurazione.

Advanced Filtering

Come Logback, Log4j 2 supporti il ​​filtraggio basato su dati di contesto, pennarelli, espressioni regolari, e altri componenti in caso Log. Il filtro può essere specificato per essere applicato a tutti gli eventi prima di essere passato ai Logger o mentre passano attraverso Appenders. Inoltre, i filtri possono anche essere associati ai Logger. Diversamente da Logback, è possibile utilizzare una classe Filter comune in una qualsiasi di queste circostanze.

Plugin Architettura

Log4j utilizza il modello di plugin per configurare i componenti. Pertanto, non è necessario scrivere codice per creare e configurare Appender, Layout, Pattern Converter e così via. Log4j riconosce automaticamente i plugin e li usa quando una configurazione li fa riferimento.

Supporto Proprietà

È possibile fare riferimento le proprietà in una configurazione, Log4j li sostituirà direttamente, o Log4j li passerà a un componente di fondo che dinamicamente risolverli. Le proprietà provengono dai valori definiti nel file di configurazione, nelle proprietà di sistema, nelle variabili di ambiente, nella mappa ThreadContext e nei dati presenti nell'evento. Gli utenti possono personalizzare ulteriormente i provider di proprietà aggiungendo il proprio plug-in di ricerca.