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

Rick Hillegas commented on DERBY-6350:
--------------------------------------

Thanks for that explanation, Brett. I'm wondering if your problem might be 
solved by a more general approach which would avoid getting Derby into the 
business of managing the cycling of log files. Right now, the following 
properties can be used to configure Derby to use either a custom 
java.io.OutputStream or java.io.Writer:

derby.stream.error.field
derby.stream.error.method

What if those methods were generalized slightly so that the custom log stream 
could be a java.util.logging.Logger as well? The glue code for making that work 
would be pretty simple I think. We might just need a new constructor for 
org.apache.derby.impl.services.stream.BasicHeaderPrintWriter and a small 
handler which wraps the diagnosticMessage in a java.util.logging.LogRecord( 
Level.INFO, diagnosticMessage ) entry. The cycling of log files could then be 
handled by the usual Java mechanisms for configuring Loggers.

Would this give you the flexibility you need?

Thanks,
-Rick

                
> 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