Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Date: Fri, 27 Sep 2013 11:56:02 +0000 (UTC)
From: "Brett Bergquist (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Message-ID: <JIRA.12669518.1379618631042.29682.1380282962462@arcas>
In-Reply-To: <JIRA.12669518.1379618631042@arcas>
References: <JIRA.12669518.1379618631042@arcas>
Subject: [jira] [Comment Edited] (DERBY-6350) Provide a rolling file
 implementation of derby.log
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Brett Bergquist edited comment on DERBY-6350 at 9/27/13 11:54 AM:
------------------------------------------------------------------

Patch attempt#3 for the rolling log file suppport.  This fixes an issue when using the embedded engine which does not define "derby.system.home".  This also has test implemented.

Changes of this patch:

1. The makeMethodHPW of the SingleStream has been modified to take a "canClose" parameter and all existing invocation paths except the one use by the rolling file implementation have been altered to pass in false.  While writing the test cases, it was determined that the rolling file error stream should be closed when the derby engine shuts down.  This is different from the case of derby.stream.error.method.  To support such and not duplicate code, the "canClose" parameter is added so that the BasicHeaderPrintWriter can be created as closeable.

2. The rolling file properties have their case changed to be camel case.  So "derby.stream.error.rollingfile.limit" is now "derby.stream.error.rollingFile.limit", etc.

3. RollingFileStream is changed such that if "derby.system.home" system property is not present, then "user.home" is used.  This takes care of the problem when the rolling file implementation is used by the embedded engine.

4. Tests are added:
   a) Test that "derby.stream.error.style=rollingFile" triggers the rolling file implementation
   b) Test that "derby.stream.error.style=unknownStyle" logs an error and uses the default log stream
   c) Test that "derby.stream.error.style=rollingFile" default values are respected of filenames of "derby-0.log..derby-9.log" (derby.stream.error.rollingFile.pattern=%d/derby-%g.log) and (derby.stream.error.rollingFile.count=10) and file size of 1024000 bytes (derby.stream.error.rollingFile.limit=1024000)
   d) Test that custom pattern, limit, and count are respected
   e) Test that "derby.stream.error.style=rollingFile" overrides "derby.stream.error.file", "derby.stream.error.method", "derby.stream.error.field" properties.

One more test should be written to test the interaction of "derby.infolog.append" with "derby.stream.error.style=rollingFile" but I think these tests are enough at this point to verify the implementation.


      was (Author: bbergquist):
    Patch attempt#3 for the rolling log file suppport.  This fixes an issue when using the embedded engine which does not define "derby.system.home".  This also has test implemented.
                  
> Provide a rolling file implementation of derby.log
> --------------------------------------------------
>
>                 Key: DERBY-6350
>                 URL: https://issues.apache.org/jira/browse/DERBY-6350
>             Project: Derby
>          Issue Type: Improvement
>          Components: Miscellaneous
>            Reporter: Brett Bergquist
>            Priority: Minor
>              Labels: features
>         Attachments: rollingfilelog.patch.txt, rollingfilelog.patch.txt, rolling_file_patch_3.txt
>
>
> By default, derby.log grows without bounds if the derby.infolog.append property is set to "true".   Setting this to "true" helps in a hands off production environment to ensure that if Derby restarts, the derby.log which might contain important information is not lost.  On the other hand, when set the "true" the derby.log grows without bounds.  This is problematic in a long running system.  
> What is really needed is the ability to have a rolling derby.log file support where the maximum file size and maximum number of files can be specified.  Derby has the ability to configure the location of the log file (ie. derby.stream.error.file) and also two methods of redirecting the error stream (.ie derby.stream.error.method and derby.stream.error.field).  There is no standard implementation that supports a rolling derby.log however.
> This facility should be part of the core Derby system so that it works in both embedded and network server models.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira