Giant NodeManagerLogs from hibernate in weblogic
Question
One of our weblogic 8.1s has suddenly started logging giant amounts of logs and filling the disk.
The logs giving us hassel resides in
mydrive:\bea\weblogic81\common\nodemanager\NodeManagerLogs\generatedManagedServer1\managedserveroutput.log
and the entries in the logfile is just the samekinds of entrires repeated again and again. Stuff like
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
I cant find any debug settings set anywhere. Ive looked in the Remote Start classpath and Arguments for the managed server.
Can anyone point me in the direction to gain control over this logfile?
Solution
Since those log entries aren't problems, it sounds like the global log level has been turned up to DEBUG. Alternatively, perhaps a new Logging mechanism has been implemented or a new log Appender that writes to stdout, and thus is being re-logged by Weblogic. I would look at the configuration of your logger. (Or provide it with one, if it is using a default config)
For example, when using Hibernate with an active Log4J setup, Hibernate will automatically join in with the Log4J instance that you set up in your own application
It can be tuned, as per the normal Log4J config. This example uses the properties configuration style:
log4j.category.org.hibernate=WARN
Hibernate may join in with other logging mechanisms via the apache commons logging API. Look at how to configure your own logger and tune out the org.hibernate.* frequencies.
n.b. When debugging, switching back on
log4j.category.org.hibernate.SQL=INFO or DEBUG
can be useful.
OTHER TIPS
Is it a large system with many programmers? If so it might be worth checking that nowhere in the code is the logger having its config changed programatically.
In log4j, this can be done using the LogManager
or BasicConfigurator
classes. Also via the PropertyConfigurator
and DomConfigurator
. Just one rogue line of code could set up a new Logger to stdout using the PatternLayout shown in your example.
BasicConfigurator.configure();