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

and so on.

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?

Answer 1

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.

Answer 2

The strange thing is that everything else logs to another log, as setup in the configuration console. The debug to stdout is not set either :(

---

Hmm. Its a giant project. Ill try a grep for some of those things

Answer 3

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();