db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <Richard.Hille...@Sun.COM>
Subject Re: regarding derby.log being overwritten on startup. [was Re: [jira] Commented: (DERBY-515) Network Server should log server start and shutdown time to derby.log]
Date Fri, 19 Aug 2005 19:05:23 GMT
At the risk of overloading this topic: While we're talking about 
improvements to our error logging, I'd like to see us emit more 
structured logs. This is one of the things that xml is actually good 
for. It would be pretty easy to turn our log records into xml entries. 
This would make it easy to write or use off-the-shelf tools for viewing 
the logs and for filtering signal out of the noise.


David Van Couvering wrote:

> 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 <kmarsdenderby@sbcglobal.net>
>>>    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
>>> 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.

View raw message