logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bruno Melloni" <Bruno.Mell...@wnco.com>
Subject RE: Dual logging problem - outofmemoryerror... heap space
Date Wed, 08 Oct 2008 14:37:20 GMT
This might be a dumb question/answer... but instead of using the spy
class, why not stick to the RollingFileAppender and simply increase the
max file size or the number of backup files kept, so that you keep
enough logs?
 
Or, if you don't have the disk space, why not use the finer grain
control - by package or class - in log4j.properties so that you only
send to the logs the 'critical information' instead of everything?  That
way your logs will be smaller.
 
BTW, you may even have an unrelated memory leak that is reducing the
memory available to log4j. 
 
bruno
 
________________________________

From: Johan Sandgren [mailto:jsa@svep.se] 
Sent: Wednesday, October 08, 2008 3:20 AM
To: log4j-user@logging.apache.org
Subject: Dual logging problem - outofmemoryerror... heap space



 

Hi,

 

Need advice from professionals here... I'm stuck! L

 

I'm using log4j, and my logs are rotating quite fast, so if an error
occurs, for example in the middle of the night, it will not be present
in the log in the morning when I arrive to check for errors.

 

So I decided to extract the errors live, when they occur, and make them
go to another file.

But since errors just on their own does not say much of where the
program were and what was the variables right then, I'd also like to
attach some history before the error in the error.log-file.

 

So I wrote a class to support this feature. It's a spy really. It's
attaching to an existing logger, and adding another appender, which I
use to create history and outputting to another error.log-file when I
need to.

 

 

A little more details on the spyclass are:

 

I'm calling my usual logger X, and I've created another loggerclass Y,
which attaches another appender on my X.

 

For each logger call with X, I also call my Y which is getting the
string too, because it's snooping on X, via this appender I added. Y is
also keeping a circularbuffer of history of all logging it gets.

When Y is called with error, fatal or warn, it will do a dump of the
history and lastly, the erranous line, and all this to another file,
error.log.

 

That way I will get my usual log in blabla.log, and for each warn, error
/fatal, I get a few lines of history + the error/warn/fatal-line that is
to be noticed.

 

 

My problem:

BUT, I get out of heapmemory when using it after a while.

I cannot find the error causing it. Mayber I'm misusing the appender or
log4j?

 

I've attached the historymaking class "ErrorLogger.java", and an example
(test.java) of how the calls are made.

 

 

 

Exception in thread "Thread-5" java.lang.OutOfMemoryError: Java heap
space

        at
java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.jav
a:99)

        at
java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:393)

        at java.lang.StringBuffer.append(StringBuffer.java:225)

        at java.io.StringWriter.write(StringWriter.java:79)

        at
org.apache.log4j.helpers.QuietWriter.write(QuietWriter.java:47)

        at
org.apache.log4j.WriterAppender.subAppend(WriterAppender.java:301)

        at
org.apache.log4j.WriterAppender.append(WriterAppender.java:159)

        at
org.apache.log4j.AppenderSkeleton.doAppend(AppenderSkeleton.java:230)

        at
org.apache.log4j.helpers.AppenderAttachableImpl.appendLoopOnAppenders(Ap
penderAttachableImpl.java:65)

        at org.apache.log4j.Category.callAppenders(Category.java:203)

        at org.apache.log4j.Category.forcedLog(Category.java:388)

        at org.apache.log4j.Category.debug(Category.java:257)

 

        at
com.sttcare.alarmSwitch.JmsTester.activeMqIsUp(JmsTester.java:88) calls
connection.stop(); So it really has nothing with log4j, I guess the heap
is just ended right then.

 

        at
com.sttcare.alarmSwitch.systemWatch.ProgramChecker.activeMQWorks(Program
Checker.java:143)

        at
com.sttcare.alarmSwitch.systemWatch.ProgramChecker.run(ProgramChecker.ja
va:119)

        at java.lang.Thread.run(Thread.java:595)

 

 

Seems to me something is exandCapacity too much... 

 

/Johan

 

_______________

Johan Sandgren    

Svep Design Center AB                                

Phone +46 46 192 722

Mobile +46 70 173 4152

Box 1233, 221 05 Lund, Sweden                                  

E-mail   jsa@svep.se

Website www.svep.se <http://www.svep.se/> 

 


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message