db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Van Couvering <David.Vancouver...@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 18:15:27 GMT
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> 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.


Mime
View raw message