<br><div class="gmail_quote">On Fri, Dec 2, 2011 at 3:38 PM, Jachym Holecek <span dir="ltr"><<a href="mailto:freza@circlewave.net">freza@circlewave.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
# Max Lapshin 2011-12-02:<br>
<div class="im">> No logger can reduce messages with current state of OTP.<br>
<br>
</div>Nor is it sensible logger's job to inspect or modify messages in any<br>
way. Just send them to backing store with minimum hassle and make<br>
best effort to minimize runtime impact on the caller. IMHO.<br>
<div class="im"><br>
> <a href="https://github.com/erlyvideo/erlyvideo/blob/master/apps/erlyvideo/src/core/gen_server_ems.erl#L747" target="_blank">https://github.com/erlyvideo/erlyvideo/blob/master/apps/erlyvideo/src/core/gen_server_ems.erl#L747</a><br>

><br>
> this is where you need to move to protect your system from silly OOM<br>
> while printing error message.<br>
<br>
</div>Yep, that's the right thing to do -- message originator is responsible<br>
for what the message looks like. To a logger it's just a data blob<br>
decorated with originator identity, or something else telling it<br>
where that message belongs. IMHO.<br>
<br>
BR,<br>
        -- Jachym<br><br></blockquote><div><br>Weeell, I think there is good cause for splitting logging into two parts: 1. creating log entries and 2. presenting them for human consumption.<br><br>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.<br>
<br>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.<br>
<br>Finally, a good design pattern for OTP behaviour implementations is to keep the state small!<br><br>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?)<br>
<br>/Robby<br><br></div></div>