Giant NodeManagerLogs von Hibernate in Weblogic

Question

Einer unserer Weblogic 8.1s hat plötzlich begonnen, riesige Mengen von Logs zu protokollieren und die Festplatte zu füllen.

Die Protokolle uns hassel geben residiert in

mydrive:\bea\weblogic81\common\nodemanager\NodeManagerLogs\generatedManagedServer1\managedserveroutput.log 

und die Einträge in der Log-Datei ist nur die samekinds von entrires wieder und wieder wiederholt. Sachen wie

19:21:24,470 DEBUG [StdRowLockSemaphore] Lock 'TRIGGER_ACCESS' returned by: LLL-SCHEDULER_QuartzSchedulerThread 
19:21:31,923 DEBUG [StdRowLockSemaphore] Lock 'STATE_ACCESS' is deLLLred by: QuartzScheduler_LLL-SCHEDULER-NACDLLLF011219763113220_ClusterManager 
19:21:31,923 DEBUG [StdRowLockSemaphore] Lock 'STATE_ACCESS' is being obtained: QuartzScheduler_LLL-SCHEDULER-NACDLLLF011219763113220_ClusterManager 
19:21:31,923 DEBUG [StdRowLockSemaphore] Lock 'STATE_ACCESS' given to: QuartzScheduler_LLL-SCHEDULER-NACDLLLF011219763113220_ClusterManager 
19:21:31,923 DEBUG [StdRowLockSemaphore] Lock 'TRIGGER_ACCESS' is deLLLred by: QuartzScheduler_LLL-SCHEDULER-NACDLLLF011219763113220_ClusterManager 

...

19:17:46,798 DEBUG [CascadingAction] cascading to saveOrUpdate: mypackage.config.common.Share 
19:17:46,798 DEBUG [DefaultSaveOrUpdateEventListener] reassociated uninitialized proxy 
19:17:46,798 DEBUG [Cascade] done processing cascade ACTION_SAVE_UPDATE for: mypackage.config.common.FileLocation 
19:17:46,798 DEBUG [Cascade] processing cascade ACTION_SAVE_UPDATE for: mypackage.config.common.FileLocation 
19:17:46,798 DEBUG [CascadingAction] cascading to saveOrUpdate: mypackage.config.common.Share 
19:17:46,798 DEBUG [DefaultSaveOrUpdateEventListener] reassociated uninitialized proxy 

ich keine Debug-Einstellungen überall gesetzt finden können. Ive sah in der Remote-Start Klassenpfad und Argumente für den verwalteten Server.

Kann mir jemand in die Richtung zeigen, um Kontrolle über dieses Logfile zu bekommen?

Answer 1

Da diese Log-Einträge keine Probleme sind, klingt es so, als ob die globale Log-Ebene auf DEBUG gestellt wurde. Alternativ wurde vielleicht ein neuer Logging-Mechanismus implementiert oder ein neuer Log-Appender, der auf stdout schreibt und somit von Weblogic erneut protokolliert wird. Ich würde mir die Konfiguration Ihres Loggers anschauen. (Oder bieten sie mit einem, wenn es einer Standardkonfiguration verwendet)

Wenn zum Beispiel mit einem aktiven Log4J Setup Hibernate, Hibernate automatisch mit der Log4J Instanz verbindet, dass Sie in Ihrer eigenen Anwendung einrichten

Es kann abgestimmt werden, wie in der normalen Log4J-Konfiguration. Dieses Beispiel verwendet die Eigenschaften Konfiguration Stil:

log4j.category.org.hibernate=WARN 

Hibernate kann mit anderen Logging-Mechanismen über die Apache Commons mitmachen Anmeldung API. Sehen Sie sich an, wie Sie Ihren eigenen Logger konfigurieren und die org.hibernate. * -Frequenzen ausblenden.

n.b. Beim Debugging kann das Zurückschalten auf

log4j.category.org.hibernate.SQL=INFO or DEBUG 

nützlich sein.

Answer 2

Ist es ein großes System mit vielen Programmierern? Wenn es so ist, könnte es sich lohnen, zu überprüfen, dass der Logger nirgends im Code programmatisch seine Konfiguration ändert. In Log4j kann dies mit den Klassen LogManager oder BasicConfigurator geschehen. Auch über die PropertyConfigurator und DomConfigurator. Nur eine bösartige Codezeile könnte einen neuen Logger einrichten, der mit dem PatternLayout, das in Ihrem Beispiel gezeigt wird, stdout wird.

BasicConfigurator.configure();