<div dir="auto">Hi,<div dir="auto"><br></div><div dir="auto">Sync/async logging was a common issue with lager too. I highly suggest not to use sync logging to avoid extra timeout issues which is pretty hard to debug.</div><div dir="auto"><br></div><div dir="auto">Dropping the whole sinks (the whole pending logger message queue) was an option for lager.</div><div dir="auto"><br></div><div dir="auto">Better option would be to count how many events are logged from each location and start skipping log events from too chatty locations (and log how many events were dropped accordingly). But I haven't seen such "smart" code anywhere yet.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 7 Aug 2020, 10:28 Steve Strong, <<a href="mailto:steve@srstrong.com">steve@srstrong.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I think a child process to perform the synchronous logging would work fine - something like:<br>
<br>
child(Server) -><br>
  receive<br>
    {do_log, Ref, From, Msg} -><br>
      try<br>
        Res = gen_server:call(Server, Msg),<br>
        From ! {Ref, {completed, Res}}<br>
      catch<br>
        _:{timeout,_} -> <br>
          From ! {Ref, timeout}<br>
      end;<br>
<br>
    {Ref, ok} -><br>
      ok;<br>
<br>
    {Ref, dropped} -><br>
      ok<br>
  end,<br>
  child(Server).<br>
<br>
(I doubt that even compiles, but should give the idea!) - when logger_olp is in sync mode, instead of it doing the gen_server:call, it sends a do_log message to the child and then waits for the response, which it is guaranteed to get.  Any timeouts are caught in the child, and any resulting stray replies will also be getting sent to the child where they can be dropped<br>
<br>
> On 7 Aug 2020, at 09:14, Łukasz Niemier <<a href="mailto:lukasz@niemier.pl" target="_blank" rel="noreferrer">lukasz@niemier.pl</a>> wrote:<br>
> <br>
>> In the event of a timeout, it is handling the exception dropping the log request.  And it’s when this occurs that there’s a problem - the gen_server call to the handler is obviously still in operation, even though the caller (logger, in this case) has timed out and moved on.  At some point it completes, and a message of {Ref, ok} or {Ref, dropped} gets returned to the caller.<br>
> <br>
> I am working on the "public" version of logger_olp so I can check out that, but I do not think that much could be done there except of just handling and dropping the stray messages in the handling process itself as in one way or another there will be need to fetch the state of the process. So in the end, there always be some call that can timeout and will result in stray messages.<br>
> <br>
> --<br>
> <br>
> Łukasz Niemier<br>
> <a href="mailto:lukasz@niemier.pl" target="_blank" rel="noreferrer">lukasz@niemier.pl</a><br>
> <br>
<br>
</blockquote></div>