Well, the most common solution is log rotation. On restart, you rename
the old log to derby.log.1 and then derby.log.2 and so on. After <n>
log files, you start over again at derby.log.1.
This is also useful for long-running systems so you don't run out of
disk space because of your error logs. When the error log gets a
configurable X MBs, the system copies the log to derby.log.1,
derby.log.2, etc., and starts a fresh log. After N log files it starts
back at 1 and overwrites the old log file. Similar but different from
above, but both are great to reduce administrative overhead for the user.
David
Sunitha Kambhampati wrote:
Øystein Grøvlen wrote:
"KM" == Kathey Marsden <[EMAIL PROTECTED]> writes:
KM> Øystein Grøvlen (JIRA) wrote:
>> [ >> This would be even more helpful if the derby.log file
was not overwritten on the next startup. (Probably a separate issue).
>> >> >> KM> The derby.infolog.append property is helpful
in this regard.
KM> http://db.apache.org/derby/docs/10.1/tuning/rtunproper13217.html
Thanks, Kathey, that is really what I need.
One concern I have is that by default, the derby.log gets overwritten
on subsequent boot. From my experience with customers, whenever there
is an issue, I always end up telling them to add this property almost
every time to see the debug logs. It is very common to see users
reboot the system if they hit an error and in this case, it is
probable that important relevant information in the derby.log is lost
because it gets overwritten ( ex - recovery issues , deadlock etc ).
Maybe we could do something smart for derby.log , a balance between
keeping history across boots and disk space taken by the derby.logs.
Any comments ?
Sunitha.
begin:vcard
fn:David Van Couvering
n:Van Couvering;David
org:Sun Microsystems, Inc.;Database Technology Group
email;internet:[EMAIL PROTECTED]
title:Senior Staff Software Engineer
tel;work:510-550-6819
tel;cell:510-684-7281
x-mozilla-html:TRUE
version:2.1
end:vcard
