[
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)
