NodeManagerLogs gigantes da hibernação no weblogic

Question

Um de nossos weblogic 8.1 de repente começou a registrar grandes quantidades de logs e a encher o disco.

Os logs que nos dão hassel residem em

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

e as entradas no arquivo de log são exatamente os mesmos tipos de entradas repetidas continuamente.Coisas 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

Não consigo encontrar nenhuma configuração de depuração definida em nenhum lugar.Procurei no caminho de classe e argumentos do Remote Start o servidor gerenciado.

Alguém pode me indicar a direção para obter controle sobre esse arquivo de log?

Answer 1

Como essas entradas de log não são problemas, parece que o nível de log global foi aumentado para DEBUG.Alternativamente, talvez um novo mecanismo de registro tenha sido implementado ou um novo log Appender que grava no stdout e, portanto, está sendo registrado novamente pelo Weblogic.Eu examinaria a configuração do seu logger.(Ou forneça um, se estiver usando uma configuração padrão)

Por exemplo, ao usar o Hibernate com uma configuração ativa do Log4J, o Hibernate se juntará automaticamente à instância do Log4J que você configurou em seu próprio aplicativo.

Ele pode ser ajustado de acordo com a configuração normal do Log4J.Este exemplo usa o estilo de configuração de propriedades:

log4j.category.org.hibernate=WARN

O Hibernate pode se juntar a outros mecanismos de registro por meio da API de registro do Apache Commons.Veja como configurar seu próprio logger e desligar as frequências org.hibernate.*.

n.b.Ao depurar, ligar novamente

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

pode ser útil.

Answer 2

É um sistema grande com muitos programadores?Nesse caso, pode valer a pena verificar se em nenhum lugar do código o logger está tendo sua configuração alterada programaticamente.

No log4j, isso pode ser feito usando o LogManager ou BasicConfigurator Aulas.Também através do PropertyConfigurator e DomConfigurator.Apenas uma linha de código não autorizada poderia configurar um novo Logger para stdout usando o PatternLayout mostrado no seu exemplo.

BasicConfigurator.configure();