Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Date: Wed, 25 Sep 2013 18:12:04 +0000 (UTC)
From: "Brett Bergquist (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Message-ID: <JIRA.12669518.1379618631042.18201.1380132724701@arcas>
In-Reply-To: <JIRA.12669518.1379618631042@arcas>
References: <JIRA.12669518.1379618631042@arcas>
Subject: [jira] [Commented] (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=13777840#comment-13777840 ] 

Brett Bergquist commented on DERBY-6350:
----------------------------------------

Thanks for volunteering to take a look at this Mamta.  I have backported it to 10.9.1.1 (my local modified copy and am using it now in production).  

I will take a look at the tests and the jira that you pointed out.  

As to your question on soft upgrade versus hard upgrade, since this introduce no change in the database at all in terms of the API, data structures, or anything else visible at that database level, only a logging facility as part of the engine, I think it should be available on a soft upgrade and I have made no coding to enforce that it not be.

What is your thoughts on this.
                
> 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
>
>
> 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