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
that.
Cheers,
-Rick
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 <[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.
