NodeManagerLogs gigantes de hibernação no WebLogic

votos
2

Um dos nossos 8.1s WebLogic, de repente, começou registrando quantidades gigantescas de toras e encher o disco.

Os logs dando-nos hassel reside em

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

e as entradas no arquivo de log é apenas o samekinds de entrires repetidos uma e outra vez. 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

Eu não posso encontrar todas as configurações de depuração definidas em qualquer lugar. Ive olhou no classpath Iniciar remoto e Argumentos para o servidor gerenciado.

Alguém pode me apontar na direção para ganhar controle sobre esse arquivo de log?

Publicado 27/08/2008 em 10:50
fonte usuário
Em outras línguas...                            


2 respostas

votos
1

Desde as entradas de log não são problemas, parece que o nível de registro global tem sido virou-se para depurar. Como alternativa, talvez um novo mecanismo de registro foi implementado ou um novo Appender log que grava stdout, e, portanto, está sendo re-registrado pelo Weblogic. Eu olhava para a configuração do seu registrador. (Ou fornecê-lo com um, se ele estiver usando uma configuração padrão)

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

Ele pode ser ajustado, de acordo com a configuração normal, Log4J. Este exemplo utiliza o modelo propriedades de configuração:

log4j.category.org.hibernate=WARN

Hibernate pode juntar-se com outros mecanismos de registro através das apache commons logging API. Olhe como configurar seu próprio logger e sintonizar o org.hibernate. * Freqüências.

nb Quando a depuração, a mudança de volta

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

pode ser útil.

Respondeu 27/08/2008 em 12:05
fonte usuário

votos
1

É um sistema grande, com muitos programadores? Se assim for, pode ser útil verificar que em nenhuma parte do código é o logger tendo a sua configuração mudado programaticamente.

Em log4j, isso pode ser feito usando o LogManagerou BasicConfiguratorclasses. Também através do PropertyConfiguratore DomConfigurator. Apenas uma linha desonestos de código poderia configurar um novo Logger para stdout usando o PatternLayout mostrado no seu exemplo.

BasicConfigurator.configure();
Respondeu 28/08/2008 em 11:38
fonte usuário

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more