Giant NodeManagerLogs de hibernación en weblogic

Question

Uno de nuestros weblogic 8.1 de repente comenzó a registrar cantidades gigantescas de registros y a llenar el disco.

Los troncos que nos dan problemas residen en

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

y las entradas en el archivo de registro son exactamente el mismo tipo de entradas repetidas una y otra vez.Cosas como

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

No puedo encontrar ninguna configuración de depuración establecida en ningún lado.He buscado en la ruta de clase de inicio remoto y en los argumentos para el servidor administrado.

¿Alguien puede indicarme cómo obtener control sobre este archivo de registro?

Answer 1

Dado que esas entradas de registro no son problemas, parece que el nivel de registro global se ha elevado a DEBUG.Alternativamente, tal vez se haya implementado un nuevo mecanismo de registro o un nuevo Appender de registro que escribe en la salida estándar y, por lo tanto, Weblogic lo vuelve a registrar.Yo miraría la configuración de su registrador.(O proporciónele uno, si está usando una configuración predeterminada)

Por ejemplo, cuando utilice Hibernate con una configuración de Log4J activa, Hibernate se unirá automáticamente a la instancia de Log4J que configuró en su propia aplicación.

Se puede ajustar según la configuración normal de Log4J.Este ejemplo utiliza el estilo de configuración de propiedades:

log4j.category.org.hibernate=WARN

Hibernate puede unirse a otros mecanismos de registro a través de la API de registro de Apache Commons.Mire cómo configurar su propio registrador y desconectar las frecuencias org.hibernate.*.

nótese bien.Al depurar, volver a encender

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

puede ser útil.

Answer 2

¿Es un sistema grande con muchos programadores?Si es así, podría valer la pena verificar que en ninguna parte del código se cambie la configuración del registrador mediante programación.

En log4j, esto se puede hacer usando el LogManager o BasicConfigurator clases.También a través del PropertyConfigurator y DomConfigurator.Solo una línea de código maliciosa podría configurar un nuevo registrador para la salida estándar usando el PatternLayout que se muestra en su ejemplo.

BasicConfigurator.configure();