Path: csiph.com!usenet.pasdenom.info!aioe.org!.POSTED!not-for-mail From: Novice Newsgroups: comp.lang.java.programmer Subject: Re: Logging problem Date: Sat, 10 Mar 2012 01:59:06 +0000 (UTC) Organization: Your Company Lines: 75 Message-ID: References:

<7aw6r.13692$wd1.4427@newsfe13.iad> NNTP-Posting-Host: aorhoX7wqL+zg222N4gRzA.user.speranza.aioe.org X-Complaints-To: abuse@aioe.org User-Agent: Xnews/5.04.25 X-Antivirus-Status: Clean X-Notice: Filtered by postfilter v. 0.8.2 X-Antivirus: avast! (VPS 120309-0, 2012-03-09), Outbound message Xref: csiph.com comp.lang.java.programmer:12822 Arved Sandstrom wrote in news:7aw6r.13692$wd1.4427@newsfe13.iad: > On 12-03-09 05:32 PM, Novice wrote: >> Arved Sandstrom wrote in >> news:Mit6r.5211$v11.1861@newsfe20.iad: >> >>> On 12-03-09 01:36 AM, Novice wrote: >>> [ SNIP ] >>>> >>>> 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 tag. >>>> >>> In a real-world production situation odds are you're getting errors >>> logged all the time. There are a whole bunch of errors that will >>> happen, sometimes frequently, sometimes a few times a day, sometimes >>> once a month, but you know they _will_ happen. So routine errors get >>> logged all the time. >>> >> I'm a little surprised by that. I would have thought actual errors >> would get acted on fairly quickly, particulary anything categorized >> as SEVERE. (I'll use the java.util.logging levels for these remarks.) >> I could see that something that is categorized as WARNING may take >> longer to fix, especially if WARNING is used for messages that >> indicate the program is able to continue using some kind of alternate >> strategy; if the alternate strategy is perfectly reasonable and >> doesn't skew the result, there's no great harm in leaving the problem >> unsolved. But if we assume that a SEVERE error is a show-stopper, >> wouldn't that get dealt with right away? > [ SNIP ] > > When I use the term "error" here, I mean conditions that correspond to > severity levels 3 (Error) and 4 (Warning) of Syslog (RFC 5424, > http://tools.ietf.org/html/rfc5424, also see > http://en.wikipedia.org/wiki/Syslog#Severity_levels). These levels > translate to ERROR and WARN of log4j. java.util.logging has WARNING > that maps to syslog 4, but doesn't have enough granularity with SEVERE > to capture the necessary distinction between syslog 0-2 (Emergency, > Alert, Critical) and 3 (Error); log4j does that reasonably well with > ERROR and FATAL. > > Syslog describes Error (level 3) means a non-urgent failure. Admins or > developers have some time frame (other than "yesterday") to resolve > the problem. This is the kind of error that happens a lot, overall, > and 99.99% of them have to do with network printing. > > Just kidding (about the printing). But you get the idea, a syslog > Error is an operational error. Your app identified a problem through > good error-handling and basically decided it couldn't proceed, but the > app itself is not at risk. Maybe a file provided by an external system > is malformed, and input processing for a scheduled import job aborts. > That's a syslog 3 Error - depending on the nature of the import and > when it happened you might have hours or days to fix the problem. > > Your impressions of what the levels mean aren't exactly wrong. If we > take j.u.l SEVERE as syslog 0-2 and j.u.l WARNING as syslog 4 then > they map OK, and your descriptions are pretty good. But > java.util.logging is missing that important syslog 3 mapping, and in > order to make j.u.l levels useable you need to add it. IMHO. But > that's one of the reasons I prefer log4j. I don't even know what the > Sun developers were thinking when they left that one out...maybe they > don't use logs. > Thanks for the clarification Arved. It all makes perfectly good sense the way you explain it - just as I expected it would ;-) -- Novice