views:

861

answers:

5

This is intended to be a lightweight generic solution, although the problem is currently with a IIS CGI application that needs to log the timeline of events (second resolution) for troible shooting a situation where a later request ends up in the MySQL database BEFORE the earlier request!

So it boils down to a logging debug statements in a single text file.

I could write a service that manages a queue as suggested in this thread: http://stackoverflow.com/questions/119548/problem-in-writing-to-single-file-in-web-service-in-net but deploying the service on each machine is a pain

or I could use a global mutex, but this would require each instance to open and close the file for each write

or I could use a database which would handle this for me, but it doesnt make sense to use a database like MySQL to try to trouble shoot a timeline issue with itself. SQLite is another possability, but this thread

http://www.perlmonks.org/?node_id=672403

Suggests that it is not a good choice either.

I am really looking for a simple approach, something as blunt as writing to individual files for each process and consolidating them accasionally with a scheduled app. I do not want to over engineer this, nor spend a week implementing it. It is only needed occassionally.

Suggestions?

+3  A: 

Tryb the simplest solution first - each write to the log opens and closes the file. If you experience problems with this, which you probably won't , look for another solution.

anon
A: 

My suggestion is to preserve performance then think in asynchronous logging. Why not send your data log info using UDP to service listening port and he write to log file.

lsalamon
Bad idea, because UDP is not reliable enough for this - you don't want to miss any messages.
anon
A: 

I would also suggest some kind of a central logger that can be called by each process in an asynchronous way. If the communication is UDP or RPC or whatever would be an implementation detail.

VVS
The guy just wants a simple debug log, not some enterprise-wide messaging architecture!
anon
+1  A: 

You can use file locking. Lock the file for writing, write the message, unlock.

Eugene Morozov
A: 

Even thought it's an old post, has anyone got an idea why not using the following concept:

  1. Creating/opening a file with share mode of FILE_SHARE_WRITE.
  2. Having a named global mutex, and opening it.
  3. Whenever a file write is desired, lock the mutex first, then write to the file.

Any input?

Guy
A Mutex is expensive and distorts the timing of events that are being logged. Other than that it would work fine.
Mike Trader
Well, it might be expensive, but the guy just asked for a SIMPLE debug log. All the options suggested here are way too complicated, IMHO.Why are you saying it will distorts the timing? Let's say the timestamp for the log entry is being generated BEFORE the mutex is locked, and then it's locked and the log entry is written...Care to explain?
Guy