Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #12814
| 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 |
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 | Next — Previous in thread | Next in thread | Find similar
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