[jira] [Comment Edited] (DERBY-6350) Provide a rolling file implementation of derby.log

["Rick Hillegas (JIRA)" <ji...@apache.org>]

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

Rick Hillegas edited comment on DERBY-6350 at 9/20/13 12:56 PM:
----------------------------------------------------------------

Thanks for working on this useful feature, Brett. I haven't read the patch yet. Instead, before jumping into code, I would like to agree on the developer experience, the functional spec if you will. That will help lead discussion about the code and will hopefully give Kim all the information she needs so that she can document this feature when it's integrated into the engine.

I'll start out with a small nit: The existing Derby properties follow a camel-case convention. So I would change rollingfile to rollingFile in the new property names.

I don't think that we need to specify the location of the rolling file implementation publicly. That, in turn, will eliminate the awkwardness of exposing an impl package in the public api. So, instead of enabling rolling logging like this...

derby.stream.error.method=org.apache.derby.impl.services.stream.RollingFileStreamProvider.getOutputStream

...I think it would be simpler to enable rolling logging like this:

derby.stream.error=rollingFile

I have some questions about the meaning of the other knobs:

derby.stream.error.rollingFile.limit - Is this the maximum size of a log file before Derby rolls over to the next file in the sequence?

derby.stream.error.rollingFile.count - Is this the maximum number of log files? If so, what happens when the maximum number of log files is exhausted? Does Derby recycle, starting over by truncating the first file in the sequence?

The derby.stream.error.rollingFile.pattern expression syntax looks a little idiosyncratic to me. I wonder if it might be simpler to give the log files standard names (something like derby-1.log, derby-2.log, etc) and let the application specify a directory for holding the log files. The default directory could be derby.system.home/derby.log. So something like this:

derby.stream.error.rollingFile.dir=/Users/apps/myapp/errorlog

What are your thoughts?

Thanks,
-Rick

                
      was (Author: rhillegas):
    Thanks for working on this useful feature, Brett. I haven't read the patch yet. Instead, before jumping into code, I would like to agree on the developer experience, the functional spec if you will. That will help lead discussion about the code and will hopefully give Kim all the information she needs so that she can document this feature when it's integrated into the engine.

I'll start out with a small nit: The existing Derby properties follow a camel-case convention. So I would change rollingfile to rollingFile in the new property names.

I don't think that we need to specify the location of the rolling file implementation publicly. That, in turn, will eliminate the awkwardness of exposing an impl package in the public api. So, instead of enabling rolling logging like this...

derby.stream.error.method=org.apache.derby.impl.services.stream.RollingFileStreamProvider.getOutputStream

...I think it would be simpler to enable rolling logging like this:

derby.stream.error=rollingFile

I have some questions about the meaning of the other knobs:

derby.stream.error.rollingFile.limit - Is this the maximum size of a log file before Derby rolls over to the next file in the sequence?

derby.stream.error.rollingFile.count - Is this the maximum number of log files? If so, what happens when the maximum number of log files is exhausted? Does Derby recycle, starting over by truncating the first file in the sequence?

The derby.stream.error.rollingFile.pattern expression syntax looks a little idiosyncratic to me. I wonder if it might be simpler to give the log files standard names (something like derby-1.log, derby-2.log, etc) and let the application specify a directory for holding the log files. The default directory could be ${derby.system.home}/derby.log. So something like this:

derby.stream.error.rollingFile.dir=/Users/apps/myapp/errorlog

What are your thoughts?

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