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

Dyre Tjeldvoll commented on DERBY-6350:
---------------------------------------

First of all: A big THANK YOU for solving this issue! 

I understand that another patch is coming so this may not be relevant, but in 
the first patch I noticed that RollingFileStreamProvider.getOutputStream() 
swallows all exceptions and just returns null in in case of errors. Does that 
mean that it will silently fall back to ordinary logging or will an NPE be 
thrown? If it is the former, is there a way to warn about this (e.g. to stderr 
since logging could not be set up)? If an NPE will be thrown, I would prefer 
just propagating the exception (possibly wrapped in another exception type if 
the exception specifications are problematic).
                
> 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
>
>
> 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

Reply via email to