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 Sat, 20 Aug 2005 00:19:09 GMT
XML is kind of dreary. I like your suggested format, David. It's easier 
to read and easy enough to transform into xml for tools which groove on 


David Van Couvering wrote:

> Please, God, no :).  Machines like reading XML but people (at least 
> certain people) find it a bit horrific.
> What I have seen done in the past is using a simple delimiter format, 
> e.g.
> |Fri Aug 19 14:06:31 PST 
> 2005|org.apache.derby.engine.impl.jdbc.EmbedConnection|Thread 
> 275|Invalid user, please try again| | |
> then you can write tools that slurp this right into Excel, load into a 
> database, etc.  We did this with an app I worked on at Sybase and it 
> was quite successful.
> David
> Rick Hillegas wrote:
>> 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.
>> Cheers,
>> -Rick
>> 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 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.

View raw message