Re: Logging problem

As I started composing a reply to one one of the responders in the
thread, it occurred to me that I really wasn't clear on what was SUPPOSED
to happen with a normal log file. I had gotten as far as determining that
getTail() in XMLFormatter would write the missing</log> tag but I hadn't
really thought through what SHOULD be happening. It occurred to me that
maybe the aberrant behavior was what I _had_ been getting and maybe what
I'm seeing now actually makes sense.

Now that I've read and googled a bit more, I'm thinking I was right about
that theory, although I'm definitely not certain. But in case I'm going
down the wrong path, let me think out loud for a minute and you folks can
tell me if I'm out in left field or if I'm making sense.

After some poking around, I found close() and flush() methods in Handler,
which is abstract, and in its children and grandchildren. The one that
concerns me is FileHandler, which is the one that writes physical logs.
Also, java.util.logging.Formatter, which is abstract, and its descendants
have a getTail() method, which is what writes that missing</log> record.

It seems to me that a real log, one you'd see in a production system,
would want to execute flush() and close() and getTail() when it was about
to be closed. But what events would cause that? I went back to the
logging.properties file and rediscovered
java.util.logging.FileHandler.limit, which has a default value of 50,000.
I'll assume that's lines but it may be the number of log records too; it
doesn't much matter. I'm assuming that's how big a physical log file can
get before it needs to be closed and a new file created. In the meantime,
Java keeps writing log records to that log. The mere fact that I start or
stop a given program shouldn't have any effect on whether the log is
locked or not; the log will be available when it's needed and will get
written until it is full.

Now, what happens when it gets full? Well, if it is a continuous log, we
just keep creating new physical law files, typically with a sequential
number to distinguish it from earlier logs, e.g. log0, log1, log2, etc.
The integer just keeps going up. If it is a circular log, we keep
incrementing the integer until we hit a threshhold like 5 or 10, then
start back at 0, overwriting the old log0. If I remember correctly, Java
can do both continuous or circular logs.

Have I got this more-or-less right so far? Because that would make sense
to me based on my (somewhat vague) memories of logging in relational
databases.

If I do have that right, then the aberrant behavior was when the log was
nicely closed as soon as my program ended. (Which raises the question why
did THAT happen? But if I'm right about the log not normally getting the
</log> tag added until the log is closed because it's full, then I'm not
going to worry about the aberrant behavior. I just want to know how to
work with a log that is functioning normally.)

So, if a log normally only gets that</log> tag written when it is ready
to be closed because it's full, what happens in the real world if you
want to read a log BEFORE it's full? If there is some kind of system
crash long before the log is full, you're not going to want to wait until
the log is full; you want to read it NOW. So how what do you do? That has
to be a routine situation and there must be a routine answer. And that's
as far as I've gotten with my reasoning.

If I'm right, nothing is really broken after all and I was just finding
those log files closed and finished by sheer good luck (or having done
some stupid things that worked in my favor). In that case, I just need to
know how the rest of you arrange to read an incomplete log. Maybe there's
a standard utility that you use to read an incomplete log??

I'll stop there and wait for your feedback before I go off the rails
completely ;-)