[erlang-questions] Logger which truncates too big terms

[Robert Raschke]

On Fri, Dec 2, 2011 at 3:38 PM, Jachym Holecek <freza@REDACTED> wrote:

> # Max Lapshin 2011-12-02:
> > No logger can reduce messages with current state of OTP.
>
> Nor is it sensible logger's job to inspect or modify messages in any
> way. Just send them to backing store with minimum hassle and make
> best effort to minimize runtime impact on the caller. IMHO.
>
> >
> https://github.com/erlyvideo/erlyvideo/blob/master/apps/erlyvideo/src/core/gen_server_ems.erl#L747
> >
> > this is where you need to move to protect your system from silly OOM
> > while printing error message.
>
> Yep, that's the right thing to do -- message originator is responsible
> for what the message looks like. To a logger it's just a data blob
> decorated with originator identity, or something else telling it
> where that message belongs. IMHO.
>
> BR,
>        -- Jachym
>
>
Weeell, I think there is good cause for splitting logging into two parts:
1. creating log entries and 2. presenting them for human consumption.

Doing this means that you can forget about any pretty-printing of log
messages at the point of their creation. Such, rather heavy, processing can
be deferred to the point of actually reading the log. The latter usually
being done off line anyway.

I've started doing this by only ever logging lists of terms (using the
error_logger), always providing the module that is logging as part of this
list. I also have a modified rb (report browser) that will call a module's
format_log/1 function (if it exists) to take the logged list of terms and
return a pretty string.

Finally, a good design pattern for OTP behaviour implementations is to keep
the state small!

If you need to remember big data, there's a whole bunch of libs to help
with that. (I've not run into log size difficulties with ets, dets, or
mnesia. Anyone know of any?)

/Robby
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20111202/0561ceab/attachment.htm>