db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brett Bergquist (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-6350) Provide a rolling file implementation of derby.log
Date Fri, 20 Sep 2013 14:02:52 GMT

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

Brett Bergquist commented on DERBY-6350:

One general comment.  My goal was to touch as little of the Derby code as possible to minimize
the risk of introducing this.  In fact, besides Property.java where the property constants
are defined, there is no other code changes to Derby core.  It uses the existing ability to
redirect the error log.  If the goal of this should be changed to make this more seamless,
I don't have a problem, but again that was not my goal.

I would have liked to have provided this as a standalone extension but a couple of things
get in the way.  The logging is done by the Derby core and it was desirable to locate the
rolling log files in the same location as the existing derby.log.  But there is no readily
available way of determining the location of derby.log using the derby.stream.error.method
or derby.stream.error.field facilities provided; neither of these mechanisms provide any context
to use to lookup this location.  The second problem is if this is indeed provided in a separate
JAR, then the security policy comes into play.  The invoking code of derby.stream.error.method
contains a security policy in effect and being able to read system properties and write files
becomes restricted by that policy.  Have to change or provide a new security policy just to
get rolling log files seemed to complex and cumbersome, so I made the decision that this functionality
needs to be as part of the core of Derby so that the same security policy can be used.

Kathey Marsden indicated that having the properties of configuring the rolling file in "derby.properties"
was preferable to having another properties file and I agree so this also made the decision
to incorporate this into Derby core.

As for renaming the property from "rollingfile" to "rollingFile", I have no issue with this.

As for "derby.stream.error=rollingFile", this will imply that the normal "derby.stream.error.method"
and "derby.stream.error.field" cannot be used or we need to document the conflict resolution
if they are.  I understand that using "derby.stream.error=rollingFile" seems easier but it
does make for more documentation and code changes in Derby core.  I don't know if the benefit
is worth the trade off.

As for the "derby.stream.error.rollingFile.limit" and "derby.steam.error.rollingFile.count"
and "derby.stream.error.rollingFile.pattern", these are directly from the "java.logger.FileHandler":


with the addition of the "%d" pattern addition to represent "derby.system.home".  The semantics
of the file size limit and file count limit are the same as "java.logger.FileHandler" and
are pretty straightforward and known to the Java community I think, so my feeling is that
keeping this as similar to that is a benefit and the documentation of these can be directly
lifted from that javadoc.

Doing the changes that you suggest are possible but also seem to conflict with what is already
provided by Derby.   For example, the "derby.stream.error.file" specifies the location (and
filename) of the output of the error stream and when this is set then the "derby.stream.error.field"
and 'derby.stream.error.method" are ignored.  Right there is a conflict that is documented.
 The "derby.stream.error.method" also has a conflict resolution with "derby.stream.error.field"
that is documented.

It seems to me that adding another "derby.stream.error" property will require updating the
conflict resolution and documentation of the existing properties which is more work that I
think is worth.

Basically we are providing the user with a complete implementation that can be plugged into
Derby using the standard mechanism that already exists namely the "derby.stream.error.method"
with understanding that the implementation is part of Derby core and that the implementation
has additional properties that can be configured through "derby.properties".

My feeling is the simplicity of the integration using the mechanism already provided by Derby,
the limit of risk in the integration into Derby core, along with the familiarity of configuration
parameters that nearly match those of the "java.logger.FileHandler", and the requirement of
just adding to the documentation on configuring this facility without changing or altering
the existing documentation of the existing facilities is pretty important.

I do agree with your comment on exposing and "impl" package publicly however.  It does not
"feel right", however, I could not find another place that "felt right" either especially
with the goal of using the "derby.stream.error.method" mechanism.  

> 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

View raw message