

Smarter log handling, the case for opportunistic logging - theotown
http://zeroturnaround.com/rebellabs/attack-of-the-logs-consider-building-a-smarter-log-handler/

======
bazzargh
This (logging to a ring buffer) has been done many times - eg
[http://www.stefanrufer.ch/snipsnap/space/Virtual+Brain/Java/...](http://www.stefanrufer.ch/snipsnap/space/Virtual+Brain/Java/Debug-
Appender)

There's even an implementation built right into log4j, 13 years ago, the
SMTPAppender:
[http://svn.apache.org/viewvc/logging/log4j/trunk/src/main/ja...](http://svn.apache.org/viewvc/logging/log4j/trunk/src/main/java/org/apache/log4j/net/SMTPAppender.java?revision=308876&view=markup)

------
bmohlenhoff
So instead of writing stuff out to disk, the idea is to keep everything in
memory forever until something bad happens? Like, for instance, your machine
runs out of memory because your debug logging consumed all of it.

How is that better?

~~~
alexkus
No, you can prevent unbounded growth by using a pre-allocated cyclic buffer
and just write into that.

We have prototypes of this in our software (but not production code yet) with
buffers that default to 50MB. That gives a nice amount of debug info in the
run up to any errors.

Whenever the buffer is dumped out you simply set the begin/end pointers of the
cyclic buffer to be the same so that subsequent errors don't write out an
entire copy of the buffer again, only the new log messages since the previous
error.

------
theotown
Haha, first pull request activated!
[https://github.com/shelajev/opportunistic-
logger/pull/1](https://github.com/shelajev/opportunistic-logger/pull/1)

