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

Groups > comp.lang.java.programmer > #12773 > unrolled thread

Logging problem

Back to article view | Back to comp.lang.java.programmer

Contents

  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

Page 2 of 2 — ← Prev page 1 [2]

#12814

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

[toc] | [prev] | [next] | [standalone]

#12816

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 </log> 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.

As for how do ops support folks read ongoing stuff? Well, surely you
must have used 'tail', or perhaps opened up a decent programming text
editor on a file that's being currently written to, or even just looked
at console output. Apart from some buffering going on (none, line or
block), which really only determines if you see your stuff immediately,
very quickly or just quickly, fact is that what you're logging shows up
in your log file rapidly, and then you can read it - there's no need to
close the file.

As Arne mentioned, a file will get closed when the log file is rolled
over for size and/or time, or because the entire application stopped.
But that's a different matter.

I've worked with several app servers that routinely log some files as
XML; I can't say it's ever occurred to me to take a peek at the XML as
text and see what state it's in during ongoing writing. These are server
logs, not application logs, so I don't usually have reason to.

I'm with Arne on not using XML logs yourself. There's no need for it.
Out in the wide world users of logs will thank you for not using XML.

AHS
-- 
-- Gaiety is the most outstanding feature of the Soviet Union.
Josef Stalin, November 1935

[toc] | [prev] | [next] | [standalone]

#12817

Arved Sandstrom <asandstrom3minus1@eastlink.ca> 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 </log> 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?

> As for how do ops support folks read ongoing stuff? Well, surely you
> must have used 'tail', 

I haven't worked on Unix/Linux in a while but I have used 'tail' ;-) 
Frankly, I don't recall if it works on open files but from you've said, 
apparently it does. 

> or perhaps opened up a decent programming text
> editor on a file that's being currently written to, or even just
> looked at console output. Apart from some buffering going on (none,
> line or block), which really only determines if you see your stuff
> immediately, very quickly or just quickly, fact is that what you're
> logging shows up in your log file rapidly, and then you can read it -
> there's no need to close the file.
> 
Perfect. Existing tools that will read the file while still being written 
are what I was hoping for ;-) 

> As Arne mentioned, a file will get closed when the log file is rolled
> over for size and/or time, or because the entire application stopped.
> But that's a different matter.
>
Indeed.
 
> I've worked with several app servers that routinely log some files as
> XML; I can't say it's ever occurred to me to take a peek at the XML as
> text and see what state it's in during ongoing writing. These are
> server logs, not application logs, so I don't usually have reason to.
> 
> I'm with Arne on not using XML logs yourself. There's no need for it.
> Out in the wide world users of logs will thank you for not using XML.
> 
You and Arne and Patricia have convinced me. XML isn't the way to go 
after all, especially if it necessitates changing the way things get done 
- such as when logs get closed - or writing new tools to be able to read 
incomplete files just to be able to read XML logs. That means I can 
remove the code that closes the handler from my program which strikes me 
as a a good thing ;-)

Well, this little mishap with the XML logs has been a good thing overall 
in that it's steered me away from a problematic approach and back towards 
something that follows established practice. 

Thanks to everyone who contributed to the thread.
-- 
Novice

[toc] | [prev] | [next] | [standalone]

#12818

Novice wrote:
> Arved Sandstrom wrote: 
> > 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 </log> tag. 

As mentioned, "tail" or "tail -f".

Or vi or emacs.

Or "less".

Or just about anything.

> > 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. 

"Acted on quickly" means that it happened. 

And he said "routine errors", not "SEVERE".

Have you looked at any real system's logs?

You should.

> (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 

Not necessarily.

> 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 

Way wrong. There's always harm in leaving a WARNING unresolved. Otherwise it'd be reported at a lower level.

> SEVERE error is a show-stopper, wouldn't that get dealt with right away?

It has to happen first, then it can be dealt with. Otherwise there's nothing with which to deal.

> > As for how do ops support folks read ongoing stuff? Well, surely you
> > must have used 'tail', 
> 
> I haven't worked on Unix/Linux in a while but I have used 'tail' ;-) 
> Frankly, I don't recall if it works on open files but from you've said, 
> apparently it does. 

"man tail"

GIYF.

If it didn't work on open files, "tail -f" would be pretty useless, now wouldn't it?

> > or perhaps opened up a decent programming text
> > editor on a file that's being currently written to, or even just
> > looked at console output. Apart from some buffering going on (none,

That "console output" one should already be way familiar to you.

> > line or block), which really only determines if you see your stuff
> > immediately, very quickly or just quickly, fact is that what you're
> > logging shows up in your log file rapidly, and then you can read it -
> > there's no need to close the file.
> > 
> Perfect. Existing tools that will read the file while still being written 
> are what I was hoping for ;-) 

Basic OS knowledge here. Nothing outré about reading a file while it's being written.

Programmers need to know more than the basics of OSes, let alone have gaps in the basics.

> > As Arne mentioned, a file will get closed when the log file is rolled
> > over for size and/or time, or because the entire application stopped.
> > But that's a different matter.
> >
> Indeed.
>  
> > I've worked with several app servers that routinely log some files as
> > XML; I can't say it's ever occurred to me to take a peek at the XML as
> > text and see what state it's in during ongoing writing. These are
> > server logs, not application logs, so I don't usually have reason to.
> > 
> > I'm with Arne on not using XML logs yourself. There's no need for it.
> > Out in the wide world users of logs will thank you for not using XML.
> > 
> You and Arne and Patricia have convinced me. XML isn't the way to go 
> after all, especially if it necessitates changing the way things get done 
> - such as when logs get closed - or writing new tools to be able to read 
> incomplete files just to be able to read XML logs. That means I can 
> remove the code that closes the handler from my program which strikes me 
> as a a good thing ;-)
> 
> Well, this little mishap with the XML logs has been a good thing overall 
> in that it's steered me away from a problematic approach and back towards 
> something that follows established practice. 
> 
> Thanks to everyone who contributed to the thread.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#12819

Lew <lewbloch@gmail.com> wrote in
news:11598111.961.1331330200504.JavaMail.geo-discussion-forums@pbcr5: 

> Novice wrote:
>> Arved Sandstrom wrote: 
>> > 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 </log> tag. 
> 
> As mentioned, "tail" or "tail -f".
> 
> Or vi or emacs.
> 
> Or "less".
> 
> Or just about anything.
> 
Okay. As I said, my Unix/Linux is pretty rusty. 

>> > 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. 
>  
> 
> "Acted on quickly" means that it happened. 
> 
> And he said "routine errors", not "SEVERE".
> 
Okay, but any severity of error could be routine. 

> Have you looked at any real system's logs?
> 
No.
> You should.
> 
I agree. Can you point me to any? I don't have any. 

>> (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 
>  
> 
> Not necessarily.
> 
>> 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 
> 
> Way wrong. There's always harm in leaving a WARNING unresolved.
> Otherwise it'd be reported at a lower level. 
> 
I'm not encouraging such errors to be ignored. I'm just saying that I can 
imagine some shops might not get to them right away. For instance, maybe 
there is a long standing issue with a date routine that always raises a 
warning but the Tomcat software has a known bug that is causing it and we 
know that Apache will be fixing it eventually so we just tolerate the 
warning pending Apache's fix of Tomcat. I can picture something like that 
happening.  

>> SEVERE error is a show-stopper, wouldn't that get dealt with right
>> away? 
> 
> It has to happen first, then it can be dealt with. Otherwise there's
> nothing with which to deal. 
> 
Of course.

>> > As for how do ops support folks read ongoing stuff? Well, surely
>> > you must have used 'tail', 
>> 
>> I haven't worked on Unix/Linux in a while but I have used 'tail' ;-) 
>> Frankly, I don't recall if it works on open files but from you've
>> said, 
>  
>> apparently it does. 
> 
> "man tail"
> 
> GIYF.
>
 
> If it didn't work on open files, "tail -f" would be pretty useless,
> now wouldn't it? 
>
I'm on a Windows system, not a *nix system, and I simply don't remember 
the details of 'tail'. Yes, I could have and would have looked it up if I 
really needed to know. I was just making a passing comment that I didn't 
remember if 'tail' could read an open file. 
 
>> > or perhaps opened up a decent programming text
>> > editor on a file that's being currently written to, or even just
>> > looked at console output. Apart from some buffering going on (none,
> 
> That "console output" one should already be way familiar to you.
>
Absolutely, I've seen that. But elsewhere in one of the threads I 
started, I think there was a general concensus that we couldn't 
necessarily count on consoles being accessible to everyone who would 
ideally want access to one so I've been trying to think through things 
without taking for granted that there was was a console available. So I 
asked myself what someone without a console might experience....
 
>> > line or block), which really only determines if you see your stuff
>> > immediately, very quickly or just quickly, fact is that what you're
>> > logging shows up in your log file rapidly, and then you can read it
>> > - there's no need to close the file.
>> > 
>> Perfect. Existing tools that will read the file while still being
>> written 
>  
>> are what I was hoping for ;-) 
> 
> Basic OS knowledge here. Nothing outré about reading a file while it's
> being written. 
> 
> Programmers need to know more than the basics of OSes, let alone have
> gaps in the basics. 
> 

>> > As Arne mentioned, a file will get closed when the log file is
>> > rolled over for size and/or time, or because the entire application
>> > stopped. But that's a different matter.
>> >
>> Indeed.
>>  
>> > I've worked with several app servers that routinely log some files
>> > as XML; I can't say it's ever occurred to me to take a peek at the
>> > XML as text and see what state it's in during ongoing writing.
>> > These are server logs, not application logs, so I don't usually
>> > have reason to. 
>> > 
>> > I'm with Arne on not using XML logs yourself. There's no need for
>> > it. Out in the wide world users of logs will thank you for not
>> > using XML. 
>> > 
>> You and Arne and Patricia have convinced me. XML isn't the way to go 
>> after all, especially if it necessitates changing the way things get
>> done 
>  
>> - such as when logs get closed - or writing new tools to be able to
>> read 
>  
>> incomplete files just to be able to read XML logs. That means I can 
>> remove the code that closes the handler from my program which strikes
>> me 
>  
>> as a a good thing ;-)
>> 
>> Well, this little mishap with the XML logs has been a good thing
>> overall 
>  
>> in that it's steered me away from a problematic approach and back
>> towards 
>  
>> something that follows established practice. 
>> 
>> Thanks to everyone who contributed to the thread.
> 


-- 
Novice

[toc] | [prev] | [next] | [standalone]

#12837

On Fri, 09 Mar 2012 22:57:16 +0000, Novice wrote:

> Lew <lewbloch@gmail.com> wrote in
>> Have you looked at any real system's logs?
>> 
> No.
>> You should.
>> 
> I agree. Can you point me to any? I don't have any.
>
That is a disadvantage of using desktop Windows, which doesn't believe in 
logs. I don't know whether Windows Server uses them, so the best I can do 
is suggest that, if you have a suitable box [1], you put one of the Linux 
flavours[2] on it, have a play with it and then take a look at the files 
in /var/log/ with "less".

[1] since Linux will run well on less hardware than Windows needs, in 
general this means anything you have lying around that's now too small 
and/or slow to run current Windows releases. If you can leave it running 
and networked with your other computers you may well find it generally 
useful: a slow Linux box with big disk(s) that is running Samba makes a 
good networked print and filing system for Windows boxes and can be 
managed OK without needing an attached screen or keyboard.

[2] try Ubuntu or Fedora 14 as general purpose distributions or consider 
PuppyLinux if the box is very small and slow, e.g. a 386/486 with under 
400 MB RAM.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#12841

On 12-03-10 10:51 AM, Martin Gregorie wrote:
> On Fri, 09 Mar 2012 22:57:16 +0000, Novice wrote:
> 
>> Lew <lewbloch@gmail.com> wrote in
>>> Have you looked at any real system's logs?
>>>
>> No.
>>> You should.
>>>
>> I agree. Can you point me to any? I don't have any.
>>
> That is a disadvantage of using desktop Windows, which doesn't believe in 
> logs.

Come, come, Martin, desktop Windows isn't quite so bad. :-) Windows
events go into the Application log, the Security log or the System log
and are what we see through the Event Viewer.

It's quite decent logging actually, although the utility of the
Application log is determined entirely by what applications choose to
write to Windows events.

As a sidenote, log4j and log4net, among other frameworks, can write to
Windows events.

I don't know whether Windows Server uses them, so the best I can do
> is suggest that, if you have a suitable box [1], you put one of the Linux 
> flavours[2] on it, have a play with it and then take a look at the files 
> in /var/log/ with "less".
[ SNIP ]

AHS
-- 
Last week I helped my friend stay put. It's a lot easier'n helpin' 'em
move. I just went over to his house and made sure that he did not start
to load shit into a truck.
-- Mitch Hedberg

[toc] | [prev] | [next] | [standalone]

#12847

Arved Sandstrom wrote:
> Martin Gregorie wrote:
>> That is a disadvantage of using desktop Windows, which doesn't believe in
>> logs.
>
> Come, come, Martin, desktop Windows isn't quite so bad. :-) Windows
> events go into the Application log, the Security log or the System log
> and are what we see through the Event Viewer.

Arved's answering your question: these are examples you can see, Novice.

> It's quite decent logging actually, although the utility of the
> Application log is determined entirely by what applications choose to
> write to Windows events.

This is rather the point of understanding logs from the reader's standpoint.

It's an exercise in projective empathy. You have to project yourself into a 
future and identify with some poor shnook who has to suss out what's going on, 
and why, with a shrieking customer and nothing to go on but log output and too 
much coffee, and you have to care.

> As a sidenote, log4j and log4net, among other frameworks, can write to
> Windows events.
>
> I don't know whether Windows Server uses them, so the best I can do
>> is suggest that, if you have a suitable box [1], you put one of the Linux
>> flavours[2] on it, have a play with it and then take a look at the files
>> in /var/log/ with "less".

[SNIP/REARRANGE]

>> Novice wrote:
>>> Lew wrote:
>>>> Have you looked at any real system's logs?
>>>>
>>> No.
>>>> You should.
>>>>
>>> I agree. Can you point me to any? I don't have any.

I wonder what a Google search might reveal. Hmm, let me see, I wonder ...
(imagination running wild)
Could it be ...
<http://lmgtfy.com/?q=example+log+output>
?

 From that:
[09/03/2004 21:59:18.060 GMT]
fadef4b T:
com.ibm.mm.beans.CMBConnection
CMBConnection.connect() entered.
[09/03/2004 21:59:18.070 GMT] fadef4b T:
com.ibm.mm.beans.CMBConnection
CMBConnection._createNewDS() entered.
[09/03/2004 21:59:18.070 GMT] fadef4b
T: com.ibm.mm.beans.CMBConnection
CMBConnection._createNewDS()
=>datastore className=
com.ibm.mm.sdk.server.DKDatastoreICM
[09/03/2004 21:59:18.310 GMT] fadef4b
T: com.ibm.mm.beans.CMBConnection Args[0]
is null, no arg constructor called for
  com.ibm.mm.sdk.server.DKDatastoreICM
[09/03/2004 21:59:18.430 GMT] fadef4b
T: com.ibm.mm.beans.CMBConnection
CMBConnection._createNewDS()=>
datastore created with args=null
[09/03/2004 21:59:18.430 GMT] fadef4b
T: com.ibm.mm.beans.CMBConnection
CMBConnection.connect()=>
com.ibm.mm.CMBConnection[connection
type=0,clientURLObj=null,csURLObj=null,
serviceConnectionType=0,serviceClientURLObj=null,
serviceCsURLObj=null,dataManagementEnabled=true,
schemaManagementEnabled=
true,workflowDataManagementEnabled=true,dsType=
ICM,serverName=icmnlsdb,portNo=0,
servicePortNo=0,RMIHostname=,
serviceRMIHostname=,
userid=icmadmin,isConnected=false]
[09/03/2004 21:59:18.430 GMT] fadef4b
T: com.ibm.mm.beans.CMBConnection
Connecting to server.
Please wait...
[09/03/2004 21:59:22.486 GMT]
fadef4b
T:com.ibm.mm.beans.workflow.CMBWorkFlowDataManagement
<http://publib.boulder.ibm.com/infocenter/cmgmt/v8r3m0/index.jsp?topic=%2Fcom.ibm.troubleshooting.doc%2Ffrnm2mst21.htm>

-- 
Lew
Isn't that special?

[toc] | [prev] | [next] | [standalone]

#12854

On Sat, 10 Mar 2012 13:00:25 -0400, Arved Sandstrom wrote:

> Come, come, Martin, desktop Windows isn't quite so bad.
>
I wasn't saying it was - just that The Microsoft Way tends not to use 
logs to the extent that *NIXen do. 

I admit its been quite a while since I've used Windows in developer mode, 
but about the only place I can remember seeing good logging was from ODBC, 
and only then if it was configured on. The ODBC log entries weren't 
timestamped, but were pretty good in all other respects.[*]

OTOH every *NIX system I've used produces timestamped logs and has a 
mechanism for changing logfiles and keeping the number kept under 
control. IOW I've never see a log under Windows that let me see what had 
happened at about 02:30:15 last Wednesday but all Unices support that 
sort of thing.
 
Hey, Novice - this example below is a good example of the unexpected 
places where a decent log can come in useful.

[*] I was using the ODBC logs to help me tune one of the more 
incompetently written databases I've seen. No adequate application 
documentation of course! So, I was reduced to exercising every function 
of the application with ODBC logging turned on and then working through 
the log to work out what indexes and table storage strategies were needed 
to make the database perform: AKA doing a traditional access path 
frequency analysis after the app had gone live and promptly slowed to a 
crawl. You really can't expect a join on 25,000 accounts to be fast if 
there are no indexes to support it, though somebody had done exactly 
that. And, of course the problem didn't show up during development, which 
had populated the test database with the traditional handful of accounts: 
when each table occupies no more than one or two disk blocks all queries 
are quick.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#12839

Novice wrote:
> Lew wrote:
>> Novice wrote:
>>> Arved Sandstrom wrote:
>>>> 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</log>  tag.
>>
>> As mentioned, "tail" or "tail -f".
>>
>> Or vi or emacs.
>>
>> Or "less".
>>
>> Or just about anything.
>>
> Okay. As I said, my Unix/Linux is pretty rusty.

Wha...?

These programs run on Windows, too.

This is about OSes. Windows is like Linux in this regard.

>> Have you looked at any real system's logs?
>>
> No.
>> You should.
>>
> I agree. Can you point me to any? I don't have any.

Go to your nearest real system and ask to see the logs.

A lot of Apache projects use log4j. Run one of those.

>>>> As for how do ops support folks read ongoing stuff? Well, surely
>>>> you must have used 'tail',
>>>
>>> I haven't worked on Unix/Linux in a while but I have used 'tail' ;-)
>>> Frankly, I don't recall if it works on open files but from you've
>>> said,
>>
>>> apparently it does.
>>
>> "man tail"
>>
>> GIYF.
>>
>
>> If it didn't work on open files, "tail -f" would be pretty useless,
>> now wouldn't it?
>>
> I'm on a Windows system, not a *nix system, and I simply don't remember
> the details of 'tail'. Yes, I could have and would have looked it up if I
> really needed to know. I was just making a passing comment that I didn't
> remember if 'tail' could read an open file.
"
Windows is no different in this regard. This is about reading files as they're 
written, not Linux. You need to know the basics of OSes.

Windows the same thing happens. Substitute "Notepad" for "vi", why don't you?

And "tail" runs on Windows, too. Many programs are available for both Windows 
and Linux. It's the operating system that determines the behavior, not whether 
it's "tail" or some other program.

So stop throwing those red herrings at us, please. Take the coaching and don't 
make the excuses.

>>>> or perhaps opened up a decent programming text
>>>> editor on a file that's being currently written to, or even just
>>>> looked at console output. Apart from some buffering going on (none,
>>
>> That "console output" one should already be way familiar to you.
>>
> Absolutely, I've seen that. But elsewhere in one of the threads I
> started, I think there was a general concensus that we couldn't
> necessarily count on consoles being accessible to everyone who would
> ideally want access to one so I've been trying to think through things
> without taking for granted that there was was a console available. So I
> asked myself what someone without a console might experience....

You're mixing topics. I pointed out the console scenario in the context of 
being able to read a file while it's being written. In no wise does that carry 
over to an inference that I'm recommending its use for logging.

The point you ducked is that this is basic, fundamental, elementary, beginner 
OS knowledge that applies to Windows, too. It's stuff you should already know. 
You must understand the basics of the OS.

If you did, you'd've known that the ability of "tail" to read files as they're 
written is neither a feature of "tail" nor unique to Linux.

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

[toc] | [prev] | [next] | [standalone]

#12843

On 3/10/2012 10:56 AM, Lew wrote:
> Novice wrote:
>> Lew wrote:
>>> Novice wrote:
>>>> Arved Sandstrom wrote:
>>>>> 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</log> tag.
>>>
>>> As mentioned, "tail" or "tail -f".
>>>
>>> Or vi or emacs.
>>>
>>> Or "less".
>>>
>>> Or just about anything.
>>>
>> Okay. As I said, my Unix/Linux is pretty rusty.
>
> Wha...?
>
> These programs run on Windows, too.
>
> This is about OSes. Windows is like Linux in this regard.

You can get them for Windows.

But they are not that common on Windows.

Arne

[toc] | [prev] | [next] | [standalone]

#12848

Arne Vajhøj wrote:
> Lew wrote:
>> Novice wrote:
>>> Lew wrote:
>>>> Novice wrote:
>>>>> Arved Sandstrom wrote:
>>>>>> 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</log> tag.
>>>>
>>>> As mentioned, "tail" or "tail -f".
>>>>
>>>> Or vi or emacs.
>>>>
>>>> Or "less".
>>>>
>>>> Or just about anything.
>>>>
>>> Okay. As I said, my Unix/Linux is pretty rusty.
>>
>> Wha...?
>>
>> These programs run on Windows, too.
>>
>> This is about OSes. Windows is like Linux in this regard.
>
> You can get them for Windows.
>
> But they are not that common on Windows.

True, but irrelevant. The point is that they are just programs, and that the 
issue at hand is operating system behavior, not program behavior. What program 
is involved has no bearing - the ability to read from a file as it's being 
written is a function of the OS and file system, inherently so. It doesn't 
matter what program we cite. I mentioned that they run on Windows, too, to 
point out that the behavior is not inherent to the program. That point is 
unaffected by how common the program is. There are plenty of programs on 
Windows, too. If you don't like my example, please extend the reasoning on 
your own to apply to whatever program you do like as an example.

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

[toc] | [prev] | [next] | [standalone]

#12917

On 3/10/2012 1:10 PM, Lew wrote:
> Arne Vajhøj wrote:
>> Lew wrote:
>>> Novice wrote:
>>>> Lew wrote:
>>>>> Novice wrote:
>>>>>> Arved Sandstrom wrote:
>>>>>>> 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</log> tag.
>>>>>
>>>>> As mentioned, "tail" or "tail -f".
>>>>>
>>>>> Or vi or emacs.
>>>>>
>>>>> Or "less".
>>>>>
>>>>> Or just about anything.
>>>>>
>>>> Okay. As I said, my Unix/Linux is pretty rusty.
>>>
>>> Wha...?
>>>
>>> These programs run on Windows, too.
>>>
>>> This is about OSes. Windows is like Linux in this regard.
>>
>> You can get them for Windows.
>>
>> But they are not that common on Windows.
>
> True, but irrelevant. The point is that they are just programs, and that
> the issue at hand is operating system behavior, not program behavior.
> What program is involved has no bearing - the ability to read from a
> file as it's being written is a function of the OS and file system,
> inherently so. It doesn't matter what program we cite. I mentioned that
> they run on Windows, too, to point out that the behavior is not inherent
> to the program. That point is unaffected by how common the program is.
> There are plenty of programs on Windows, too. If you don't like my
> example, please extend the reasoning on your own to apply to whatever
> program you do like as an example.

All very true.

But I think novice was just trying to say that he was rusty in *nix
including those tools.

And that is not particular surprising if he is a Windows user.

Arne

[toc] | [prev] | [next] | [standalone]

#12853

Lew <noone@lewscanon.com> wrote in news:jjftj9$b8q$1@news.albasani.net:

> Novice wrote:
>> Lew wrote:
>>> Novice wrote:
>>>> Arved Sandstrom wrote:
>>>>> 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</log>  tag.
>>>
>>> As mentioned, "tail" or "tail -f".
>>>
>>> Or vi or emacs.
>>>
>>> Or "less".
>>>
>>> Or just about anything.
>>>
>> Okay. As I said, my Unix/Linux is pretty rusty.
> 
> Wha...?
> 
> These programs run on Windows, too.
> 
> This is about OSes. Windows is like Linux in this regard.
> 
>>> Have you looked at any real system's logs?
>>>
>> No.
>>> You should.
>>>
>> I agree. Can you point me to any? I don't have any.
> 
> Go to your nearest real system and ask to see the logs.
> 
> A lot of Apache projects use log4j. Run one of those.
> 
>>>>> As for how do ops support folks read ongoing stuff? Well, surely
>>>>> you must have used 'tail',
>>>>
>>>> I haven't worked on Unix/Linux in a while but I have used 'tail'
>>>> ;-) Frankly, I don't recall if it works on open files but from
>>>> you've said,
>>>
>>>> apparently it does.
>>>
>>> "man tail"
>>>
>>> GIYF.
>>>
>>
>>> If it didn't work on open files, "tail -f" would be pretty useless,
>>> now wouldn't it?
>>>
>> I'm on a Windows system, not a *nix system, and I simply don't
>> remember the details of 'tail'. Yes, I could have and would have
>> looked it up if I really needed to know. I was just making a passing
>> comment that I didn't remember if 'tail' could read an open file.
> "
> Windows is no different in this regard. This is about reading files as
> they're written, not Linux. You need to know the basics of OSes.
> 
> Windows the same thing happens. Substitute "Notepad" for "vi", why
> don't you? 
> 
I've had Notepad refuse to open files because they were in use. (Or was 
that Wordpad? I may be muddling the two....) Therefore, it was not 
intuitively obvious to me that Notepad would always read a file that was 
in use. 

> And "tail" runs on Windows, too. Many programs are available for both
> Windows and Linux. It's the operating system that determines the
> behavior, not whether it's "tail" or some other program.
> 
> So stop throwing those red herrings at us, please. Take the coaching
> and don't make the excuses.
> 
Coaching or bludgeoing? Sometimes it seems like you seize on even 
slightest misstep to emphasize how I am utterly wrong about something.  
This is one such case. 

The topic at hand was how an operator would access a log file that was 
still open. Someone suggested 'tail' as a tool for reading such a file. I 
mentioned in passing that I didn't know it could read an open file. I 
didn't demand that someone tell me whether it could. If I had, you could 
rightly say that I should look it up. I didn't feel any particular need 
then - nor do I now - to go out and determine all the programs on all the 
popular operating systems, including Windows, that can read an open file. 
I didn't know that tail, vi, or emacs were available in Windows versions. 
I'm not actually surprised but I didn't know it. Notepad may or may not 
be able to read an open file - I'm sure I had trouble reading at least 
one open file with either Notepad or Wordpad yesterday but I don't recall 
which - but it's not a big concern to me at this moment. I'm much more 
interested in the big picture so that I can improve my use of logs. When 
I need to read an open file in Windows, I'll figure out how to do that.  

>>>>> or perhaps opened up a decent programming text
>>>>> editor on a file that's being currently written to, or even just
>>>>> looked at console output. Apart from some buffering going on
>>>>> (none, 
>>>
>>> That "console output" one should already be way familiar to you.
>>>
>> Absolutely, I've seen that. But elsewhere in one of the threads I
>> started, I think there was a general concensus that we couldn't
>> necessarily count on consoles being accessible to everyone who would
>> ideally want access to one so I've been trying to think through
>> things without taking for granted that there was was a console
>> available. So I asked myself what someone without a console might
>> experience.... 
> 
> You're mixing topics. I pointed out the console scenario in the
> context of being able to read a file while it's being written. In no
> wise does that carry over to an inference that I'm recommending its
> use for logging. 
> 
I was only trying to find out how operators would read an open file in 
the absence of consoles. I didn't want to blithely assume that a console 
was always going to be at hand. That's all I was trying to say.

> The point you ducked is that this is basic, fundamental, elementary,
> beginner OS knowledge that applies to Windows, too. It's stuff you
> should already know. You must understand the basics of the OS.
> 
> If you did, you'd've known that the ability of "tail" to read files as
> they're written is neither a feature of "tail" nor unique to Linux.
> 
You're obviously better at remembering large numbers of things for a long 
time than I am. I tend not to remember a lot of details due to my less 
reliable memory. Therefore, I don't have a list in my head of exactly 
which programs on each of the major OSes will read open files. I just 
assume that such tools exist and that I might have some of them on my 
computer. If I need to read an open file, I use the tools I have. If they 
don't work, I look for others or maybe even build one of my own. 

I don't memorize the fact that there are Windows version of vi, emacs, 
tail, less, and so forth nor which of them can read a file that is open 
nor whether Notepad or Wordpad or the various other Windows editors can 
handle them. I've never found that I remember things like that 
particularly well. I wish I could. I muddle along as best I can within my 
limitations.

-- 
Novice

[toc] | [prev] | [next] | [standalone]

#12820

On 12-03-09 05:32 PM, Novice wrote:
> Arved Sandstrom <asandstrom3minus1@eastlink.ca> 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 </log> 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.

AHS
-- 
Last week I helped my friend stay put. It's a lot easier'n helpin' 'em
move. I just went over to his house and made sure that he did not start
to load shit into a truck.
-- Mitch Hedberg

[toc] | [prev] | [next] | [standalone]

#12822

Arved Sandstrom <asandstrom3minus1@eastlink.ca> wrote in
news:7aw6r.13692$wd1.4427@newsfe13.iad: 

> On 12-03-09 05:32 PM, Novice wrote:
>> Arved Sandstrom <asandstrom3minus1@eastlink.ca> 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 </log> 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

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.java.programmer

csiph-web