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

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

In regards to the empty "derby.log" when using the rollingFile implemenation, 
this occurs because of BaseMonitor.boot calling SingleStream.boot.   This 
occurs when Derby is started, long before it looks for any properties.  I tis 
called by ErrorStreamTest.setup/ErrrorStreamTest.bootDerby, etc.

So i don't think anything can be done about the "derby.log" being created and 
in fact I think it is probably risky to make any changes there.   In my opinion 
I think it is okay the way that it is.

I believe that this same issue will be present if you use the 
"derby.stream.error.file" property or the "derby.stream.error.field" property, 
or the "derby.stream.error.method" properties as well.  In fact, just testing 
now and during the ErrorStreamTest.testFile method by itself, it also has a 
"derby.log" present.




> 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, rolling_file_patch_7.diff
>
>
> 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)

Reply via email to