Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.java.programmer > #12814

Re: Logging problem

Date 2012-03-09 14:26 -0500
From Arne Vajhøj <arne@vajhoej.dk>
Newsgroups comp.lang.java.programmer
Subject Re: Logging problem
References (1 earlier) <jjbb75$dgo$1@dont-email.me> <XnsA010D48F8E7BFjpnasty@94.75.214.39> <XnsA0116442B9A2jpnasty@94.75.214.39> <4f5a3e85$0$291$14726298@news.sunsite.dk> <XnsA0118E029EDACjpnasty@94.75.214.39>
Message-ID <4f5a595c$0$287$14726298@news.sunsite.dk> (permalink)
Organization SunSITE.dk - Supporting Open source

Show all headers | View raw


On 3/9/2012 1:57 PM, Novice wrote:
> Arne Vajhøj<arne@vajhoej.dk>  wrote in
> news:4f5a3e85$0$291$14726298@news.sunsite.dk:
>
>> On 3/9/2012 12:36 AM, Novice wrote:
>>> Just to follow up on my own post, I've found a simple way to cause
>>> that closing tag to be written to the log file. My program is
>>> launched for a very simple JFrame that has two buttons, one for each
>>> of the two principal classes. I've added code so that when I click on
>>> the close button on the JFrame, I simply use the Logger object to
>>> determine all the handlers for that Logger. Then, I do a for each
>>> loop to go through the handlers and simply close each one. Upon
>>> completion, my physical log file has no lock file associated with it
>>> and I can open it without difficulty. When I edit the log file, I see
>>> that the</log>   tag is right where it should be.
>>
>> You should not have to do that kind of stuff.
>>
> I agree. It does seem excessive to that within the program.
>
>>> It's a bit of a sledgehammer approach to the problem but I can
>>> fine-tune it to close only the FileHandler. But it doesn't answer the
>>> question of how the situation would be handled in the real world. Are
>>> real production programs closing physical log files when they stop
>>> running? It seems unlikely that a 24x7 (or nearly 24x7) application
>>> would stop running at all except for a maintenance period yet if it
>>> starts writing error messages to its log, I can't see people waiting
>>> until the log is full before they get their hands on it and find out
>>> what's going on.
>>>
>>> It would be very helpful if someone could explain what would happen
>>> in a real-world production situation where a long-running batch
>>> program or a constantly-running online program started writing error
>>> messages to the log. What will operators do to be able to read the
>>> log? I'm guessing they force it to close early and then start a new
>>> file or they have a tool that will read the log file correctly even
>>> without the final</log>   tag.
>>
>> In a 24x7 environment I would expect:
>> * the appender to be a rolling file appender so the file get closed
>>     and anew one opened every day
>> * log output to be so big that buffers get flushed to disk within
>>     minutes so the current file can be used
>>
> But, as you've said all along and Patricia has now supported, you'd be
> writing text files, not XML, so there wouldn't be the same issue of
> having to write the closing</log>  tag (or an HTML equivalent in an HTML
> log).

I would use a flat format with one line per log message and no headers
and trailers.

>      Then again, you'd still have a lock even on a text file log, at
> least if I'm reading the API correctly, so you'd still have to force an
> early rollover of the log to be able to read the one you want to see,
> right?

No. I would expect it to be possible to read the file even though
it is open for write by the app.

> I like the fact that XML gives you lots of options about formatting the
> output the way you want it but if it causes problems like this incomplete
> file issue I may have to abandon XML logs and go back to simple text
> logs, assuming that the simple text logs will be viewable when I want
> them, even if that means having to run a simple utility to force an early
> rollover.
>
> That seems preferable to having to close handlers within my program.
> That's not such a big problem in a programmer test environment but I
> don't think a production program would be closing handlers every time the
> program ends, especially if it was some kind of online program that was
> running all the time.

Yup.

Arne


Back to comp.lang.java.programmer | Previous | NextPrevious in thread | Next in thread | Find similar


Thread

Logging problem Novice <novice@example..com> - 2012-03-08 19:38 +0000
  Re: Logging problem Arne Vajhøj <arne@vajhoej.dk> - 2012-03-08 14:48 -0500
    Re: Logging problem Novice <novice@example..com> - 2012-03-08 20:06 +0000
      Re: Logging problem Arne Vajhøj <arne@vajhoej.dk> - 2012-03-08 15:38 -0500
        Re: Logging problem Martin Gregorie <martin@address-in-sig.invalid> - 2012-03-08 22:02 +0000
      Re: Logging problem Patricia Shanahan <pats@acm.org> - 2012-03-08 14:53 -0800
        Re: Logging problem markspace <-@.> - 2012-03-08 15:20 -0800
          Re: Logging problem Arne Vajhøj <arne@vajhoej.dk> - 2012-03-08 19:48 -0500
            Re: Logging problem Patricia Shanahan <pats@acm.org> - 2012-03-08 17:17 -0800
              Re: Logging problem Arne Vajhøj <arne@vajhoej.dk> - 2012-03-08 20:55 -0500
                Re: Logging problem markspace <-@.> - 2012-03-08 18:01 -0800
                Re: Logging problem Arne Vajhøj <arne@vajhoej.dk> - 2012-03-08 21:19 -0500
      Re: Logging problem Arne Vajhøj <arne@vajhoej.dk> - 2012-03-08 20:56 -0500
  Re: Logging problem markspace <-@.> - 2012-03-08 14:18 -0800
    Re: Logging problem Novice <novice@example..com> - 2012-03-09 01:53 +0000
      Re: Logging problem Arne Vajhøj <arne@vajhoej.dk> - 2012-03-08 20:59 -0500
      Re: Logging problem Novice <novice@example..com> - 2012-03-09 05:36 +0000
        Re: Logging problem Patricia Shanahan <pats@acm.org> - 2012-03-09 06:27 -0800
        Re: Logging problem Arne Vajhøj <arne@vajhoej.dk> - 2012-03-09 12:31 -0500
          Re: Logging problem Novice <novice@example..com> - 2012-03-09 18:57 +0000
            Re: Logging problem Arne Vajhøj <arne@vajhoej.dk> - 2012-03-09 14:26 -0500
        Re: Logging problem Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-03-09 15:59 -0400
          Re: Logging problem Novice <novice@example..com> - 2012-03-09 21:32 +0000
            Re: Logging problem Lew <lewbloch@gmail.com> - 2012-03-09 13:56 -0800
              Re: Logging problem Novice <novice@example..com> - 2012-03-09 22:57 +0000
                Re: Logging problem Martin Gregorie <martin@address-in-sig.invalid> - 2012-03-10 14:51 +0000
                Re: Logging problem Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-03-10 13:00 -0400
                Re: Logging problem Lew <noone@lewscanon.com> - 2012-03-10 10:04 -0800
                Re: Logging problem Martin Gregorie <martin@address-in-sig.invalid> - 2012-03-10 20:23 +0000
                Re: Logging problem Lew <noone@lewscanon.com> - 2012-03-10 07:56 -0800
                Re: Logging problem Arne Vajhøj <arne@vajhoej.dk> - 2012-03-10 12:05 -0500
                Re: Logging problem Lew <noone@lewscanon.com> - 2012-03-10 10:10 -0800
                Re: Logging problem Arne Vajhøj <arne@vajhoej.dk> - 2012-03-12 16:13 -0400
                Re: Logging problem Novice <novice@example..com> - 2012-03-10 20:10 +0000
            Re: Logging problem Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-03-09 19:15 -0400
              Re: Logging problem Novice <novice@example..com> - 2012-03-10 01:59 +0000

csiph-web