I appreciate all the response!
We are most certainly setting our logging to error at the root level, This
is obvious because the log file created is empty, if we were in debug we
would know it because we would run out of disk space in a hurry!.
Some additional information that may help is we were looking at memory
allocated by the JVM and not through a profiler of any kind. We were running
our software on a Linux box and used the 'top' command to monitor the amount
of memory that java had allocated for its use.
In both cases we ran java.exe with out any memory parameters. Running with
no logging code we (in a short period of time) used 100mb of memory and
reached a steady state. With the log4j code inserted (though disabled by the
log4j properties file) we quickly achieved over 1 gig of memory allocated to
the java process before reaching a steady state.
Another data point to note is our code is heavily threaded and it is
possible for one category's log methods to be called from several threads.
Moreover we were running on a duel processor box so it is theoretically
possible for calls to be made simultaneously to the same category. Log4j is
advertised as thread safe so we didn't view this as an area of concern.
I will try to keep you updated with any tests results that show significant
memory usage. As I said before I am having some difficulty replicating the
problem in a simple example. Any thoughts on how to try and track this
problem down are much appreciated.
Thanks,
Jim
-----Original Message-----
From: WJCarpenter [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, December 18, 2002 4:31 PM
To: [EMAIL PROTECTED]
Subject: RE: Large Memory usage while using log4j
> Our logging was set to error (we do no error level logging). This
Another sanity-check question ... you're sure you're setting things
to log at the error level? (For example, by testing at runtime.)
If log4j sees no config file, it configures itself at DEBUG level at
the root Logger even though there are no appenders. (This makes no
sense to me, but perhaps there is a good reason for it.)
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
