My<cod/>.net
Гигантский NodeManagerLogs от hibernate в weblogic
Один из наших weblogic 8.1s внезапно начал регистрировать гигантские объемы журналов и заполнять диск.
Бревна, которые дает нам Хассель, находятся в
mydrive:\bea\weblogic81\common\nodemanager\NodeManagerLogs\generatedManagedServer1\managedserveroutput.log
и записи в лог-файле-это просто одни и те же записи entrires, повторяемые снова и снова. Такие вещи, как
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
Я не могу найти какие-либо настройки отладки, установленные в любом месте. Я посмотрел в удаленном запуске classpath и аргументы для управляемого сервера.
Может ли кто-нибудь указать мне направление, чтобы получить контроль над этим файлом журнала?
Поскольку эти записи журнала не являются проблемами, похоже, что глобальный уровень журнала был поднят до DEBUG. В качестве альтернативы, возможно, был реализован новый механизм ведения журнала или новое приложение журнала, которое записывает в stdout и, таким образом, повторно регистрируется Weblogic. Я бы посмотрел на конфигурацию вашего регистратора. (Или предоставить его с одним, если он использует конфигурацию по умолчанию)
Например, при использовании Hibernate с активной настройкой Log4J Hibernate автоматически присоединится к экземпляру Log4J, настроенному в вашем собственном приложении
Его можно настроить в соответствии с обычной конфигурацией Log4J. В этом примере используется стиль конфигурации свойств:
log4j.category.org.hibernate=WARN
Hibernate может присоединиться к другим механизмам ведения журнала через apache commons logging API. Посмотрите, как настроить свой собственный регистратор и настроить org.hibernate.* частоты.
n.b. При отладке снова включается
log4j.category.org.hibernate.SQL=INFO or DEBUG
может быть полезным.
Это большая система с большим количеством программистов? Если это так, возможно, стоит проверить, что нигде в коде регистратор не имеет своей конфигурации, измененной программно.
В log4j это можно сделать с помощью классов LogManager или BasicConfigurator . Также через PropertyConfigurator и DomConfigurator . Только одна строка кода изгоев может настроить новый регистратор на stdout, используя PatternLayout, показанный в вашем примере.
BasicConfigurator.configure();