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 21:09:53 GMT
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 
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.


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
>>>> 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