[ 
https://issues.apache.org/jira/browse/GEODE-8929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17285918#comment-17285918
 ] 

ASF subversion and git services commented on GEODE-8929:
--------------------------------------------------------

Commit ecf06115eb1bedd90d0ede9a5cc9cafff6111606 in geode-native's branch 
refs/heads/develop from Blake Bender
[ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=ecf0611 ]

GEODE-8929: fix 'leaked disk space' issue in logger (#743)

- Logger wasn't calculating the size of existing files when
  initializing.  Thus the disk usage could grow by up to the space limit
  set by the app at each iteration (run).
- Added new test to start/stop logger several times and verify we're
  never exceeding disk space limits in toto.
- passing nullptr for file name to Log::Init() wasn't writing to a
  default file, now it writes to 'geode-native.log' in CWD.
- logging test for (#) in filename wasn't cleaning up its log file
- added test code to clean up any default-named log files
- Run all unit tests with "test" filename, and with default filename
  (geode-native.log)
- Add specific case to check for "leaked" disk space when specifying
  nullptr to get the default file name.

> Existing log files not counted in disk space calculations
> ---------------------------------------------------------
>
>                 Key: GEODE-8929
>                 URL: https://issues.apache.org/jira/browse/GEODE-8929
>             Project: Geode
>          Issue Type: Bug
>          Components: native client
>            Reporter: Blake Bender
>            Priority: Major
>              Labels: pull-request-available
>
> When the native logger starts up, it looks for existing "rolled" log files, 
> i.e. files which were written by a previous instance of the client.  If it 
> finds any, they are added to an internal map, and when the current log file 
> would exceed the file size limit, the oldest existing rolled log file is 
> deleted, and a new one written.  The size of the existing files, however, is 
> not calculated and subtracted from available size at startup, so each 
> concurrent instance of the client can _add_ up to whatever is specified for 
> `log-disk-space-limit`.  So, for instance, if you set a disk space limit of 
> 5MB, run your app, generate 5MB of logs, and quit, you have 5MB of logs.  If 
> you run your app again, generate 5MB of logs, and quit, you now have 10MB of 
> logs, etc., effectively "leaking" disk space.
>  
> The workaround for now is to always delete existing log files at app startup, 
> but we should really either delete these when initializing the logger, or 
> calculate the existing used disk space at startup.
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to