Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Date: Wed, 9 Oct 2013 20:22:42 +0000 (UTC)
From: "Mike Matrigali (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Message-ID: <JIRA.12669518.1379618631042.40888.1381350162962@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=13790820#comment-13790820 ] 

Mike Matrigali commented on DERBY-6350:
---------------------------------------

to expand on what myrna pointed out.  The main difference in this area that we see between unix and windows is that windows does not
allow a file to be deleted that is currently open.  So suggest you look for missing closes of the files.

Another safety check might be to by hand to the following test:
o set up the system that is creates a large number of derby.logs in a single test run, and then use the unix tools to show
   open files.  I think the goal would be only ever one derby.log segment open at one time (or maybe an edge case of 2 or something
   like that).  We sometimes run into open file issues on derby, so 1 at a time would be a good goal or we may have to point it out
   in a release note.  There are some applications out there that have large number of databases in their application and are sensitive
   to any per-database increase in resources like open files, system threads, size, ...

> 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
>            Assignee: Brett Bergquist
>            Priority: Minor
>              Labels: features
>         Attachments: rollingfilelog.patch.txt, rollingfilelog.patch.txt, rolling_file_patch_5.txt, rolling_file_patch_6.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 was sent by Atlassian JIRA
(v6.1#6144)