Re: [Boost-bugs] [Boost C++ Libraries] #11016: Boost file logging misbehaves when file system is full

Subject: Re: [Boost-bugs] [Boost C++ Libraries] #11016: Boost file logging misbehaves when file system is full
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2015-02-13 07:48:48


#11016: Boost file logging misbehaves when file system is full
-------------------------------+---------------------
  Reporter: michi@… | Owner: andysem
      Type: Bugs | Status: new
 Milestone: To Be Determined | Component: log
   Version: Boost 1.55.0 | Severity: Problem
Resolution: | Keywords:
-------------------------------+---------------------

Comment (by andysem):

 Replying to [comment:7 Michi Henning <michi.henning@…>]:
>
> I don't think a global suppression would help, at least not in all
 cases. I'm logging from a library.

 I'm not saying global suppression. You can suppress exceptions on
 different levels, including the logger you use in your library.

> In my opinion, throwing from log methods (at least the ones that create
 log messages) is a big no-no. If a log message can't be written, there is
 typically nothing that the code that does the logging can do. All it would
 achieve is that I would have to clutter the calling code with masses of
 catch handlers.

 Have a look at exception handlers, you don't have to write try/catch
 everywhere.

> Timers wouldn't be needed. Just remember the current time if a failure
 occurs. Then, when trying to write, if in the error state, check the
 current time and, if within the ban period, skip the write. Once a write
 works, re-enter the no-error state, to avoid the overhead of checking the
 current time.

 What does such record peeling give? Other than losing some records which
 could have been written when free space appears, it doesn't seem to do any
 significant effect.

-- 
Ticket URL: <https://svn.boost.org/trac/boost/ticket/11016#comment:8>
Boost C++ Libraries <http://www.boost.org/>
Boost provides free peer-reviewed portable C++ source libraries.

This archive was generated by hypermail 2.1.7 : 2017-02-16 18:50:17 UTC