public class SimpleLogger
{
static readonly string logFile = ConfigurationManager.AppSettings["LogFile"];
static StreamWriter GetStream()
{
return File.Exists(logFile) ?
File.AppendText(logFile) : File.CreateText(logFile);
}
public static void Write(string msg)
{
using (var sw = GetStream())
{
sw.Write(msg);
}
}
}
The above code fails in use as it doesn't appear to be closing/disposing of the stream correctly. Subsequent writes give a 'file in use' IOException.
If the class is modified to use non-static methods, it appears to work correctly.
I don't understand why there would be any behavioural difference?
The disposal is fine; GetStream delivers an open writer; Write closes/disposes it - sorted. if I had to guess, though, the issue is concurrent use - i.e. multiple threads (in particular in a web application) accessing the file at the same time. If that is the case, options:
make Write (and any other access to the file) synchronized, so only one caller can possibly try to have the file open at once
use a pre-canned logging framework that will already handle this scenario (common approaches here include synchronization, but also: buffering the data locally and then pushing the data down periodically - avoids opening the file over and over and over and over)
In particular; your only static state is the file path itself. There will therefore be no significant difference between using this as a static versus instance method.
As a side-note, File.AppendAllText may be useful here, but does not avoid the issue of concurrency.
I don't think changing from a static to an instance would fix the problem since they're all ultimately contending over a static resource (the file). This answer might help you. Perhaps if you left both methods static and declared a static synchronisation object for calling threads to lock with (since the resource is static itself) would help?, e.g.:
private static object _objectLock = new object();
for synchronising access to the file from multiple threads, hence:
public static void Write(string msg)
{
lock(_objectLock)
{
using (var sw = GetStream())
{
sw.Write(msg);
}
}
}
Related
I have a very simple logging mechanism in my application which periodically writes a line to a file (a logging library would be overkill for my needs) which looks something like this:
private string logfile = #"C:\whatever.log";
public void WriteLine(string line)
{
using(FileStream fs = File.Open(logfile, FileMode.Append))
{
// Log Stuff
}
}
So any time I call that method, a new FileStream is created and disposed after logging is finished. So I considered using an already instantiated object to prevent the continuous creation of new objects:
private string logfile = #"C:\whatever.log";
private FileStream myStream = File.Open(logfile, FileMode.Append);
public void WriteLine(string line)
{
using(myStream)
{
// Log Stuff
}
}
However, the MSDN reference discourages this (last example), due to scope issues.
What does one do in that case? Is the overhead in my first example negligible?
The using statement doesn't do anything else than calling the Dispose() method of the object.
So considering your second example, after the first call to the WriteLine(string) method the filestream is disposed. So any other call, after the first one, to this Method will result in an exception.
Using the File.AppendText() method like Chris had suggested in the comment would be a way to go. But keep in mind, that using this or any other File... method will also open a stream and close and dispose it afterwards.
It will just result in less code.
The second approach does also dispose the stream every time you call WriteLine since you are also using the using-statement. MSDN discourages from this approach because the variable myStream does still "exist" even if the object is disposed. So that is more error-prone.
If you often need to use this method you should cosider to use the using "outside" or use a try-catch-finally:
var myLogger = new MyLogger();
try
{
// here is your app which calls myLogger.WriteLine(...) often
}
catch(Exception ex)
{
// log it
}
finally
{
myLogger.Dispose(); // myLogger is your Log class, dispose should call myStream.Dispose();
}
The overhead might not be negligible, but that might be beside the point.
When you are using using, the creation, acquisition of resource and the disposing of the used resources is nicely scoped. You know where it starts, where it's used, and where it's finished.
If you go for the second scenario, you know where it starts (it's when the containing class is created), but after that, you have no platform-guaranteed way to control where it's used, and where (if at all) the resources are disposed.
You can do this yourself if this is critical code, and your containing class implements the IDisposable pattern properly, but this can be tricky and not for the faint of heart :)
However, you stated in the question "a logging library would be overkill for my needs", so I think you are fine with the minimal overhead. IMHO, you should be fine with one of the ready-made File methods, like File.AppendAllText:
public void WriteLine(string line)
{
//add an enter to the end
line += Environment.NewLine;
File.AppendAllText(logfile, line);
}
or File.AppendAllLines:
public void WriteLine(string line)
{
File.AppendAllLines(logfile, new []{line});
}
I wrote this static log class to record all status during many threads. Sometimes I got a exception saying the log file(that the program is writing) was occupied. It seems other thread was writing the file at the same time. I made all this works invoke to UI thread to avoid this exception, but it still happens. Any suggestion? Thanks.
BTW, I know I may use lock(mLog) to avoid this problem, but I am still wondering why this happens, UI thread should never run 2 Log.UpdateLog functions at the same time, am I right?
public partial class LogForm : Form
{
private StringBuilder mLog;
public LogForm()
{
InitializeComponent();
mLog = new StringBuilder();
}
public void Write(string msg, bool save)
{
mLog.Insert(0, msg + "\r\n\r\n" + "-----------------------------------------------------------------------" + "\r\n\r\n");
if (save)
{
SaveFile();
}
}
private void SaveFile()
{
FileStream file;
file = new FileStream(Application.StartupPath + #"\LOG.txt", FileMode.Create);
StreamWriter sw = new StreamWriter(file);
sw.Write(mLog.ToString());
sw.Close();
file.Close();
}
}
public static class Log
{
private delegate void mUIInvoke(string msg, bool save);
private static LogForm mLogForm = new LogForm();
public static void Write(string msg, bool save)
{
msg += "\r\nTIME:" + DateTime.Now.ToShortDateString() + " " + DateTime.Now.ToShortTimeString();
if (mLogForm.InvokeRequired)
{
mUIInvoke invoke = new mUIInvoke(UpdateLog);
mLogForm.BeginInvoke(invoke, new object[] { msg, save });
}
else
{
UpdateLog(msg, save);
}
}
private static void UpdateLog(string msg, bool save)
{
mLogForm.Write(msg, save);
}
}
This is definitely not an elegant method for implementing logging as you've multiple threads in your class. If you want a better design, your logging stuffs has to be moved out from form class as logging is something independent and threads shouldn't access a "form" to "log" make it meaningful.
There are two alternatives for this.
Go for logging frameworks which are tested and proven like log4net or NLog
Make this logging class independant and create an instance (mostly a singleton though I am against singleton classes) of logger class and share it between multiple threads. file management, logging functions etc. has to be managed separately. All the operations has to be protected with thread synchronization mechanisms like mutex. There are several ways to implement a logging framework. It's all depends on how much of you really need!
Unless it's not a big deal or for learning purpose, I would suggest you to use existing logging frameworks, especially when using with production quality code.
It is not a problem of the UI thread. The problem is (mainly) in the SaveFile method. If two different threads try to access this method one could find the file still in use by the other thread. A simple lock could resolve the problem.
So immagine Thread A that call mLogForm.Write
It enters the method and reach without interruption the SaveFile method,
it open the file stream but at this point is interrupted and the OS decides to run Thread B
Thread B runs and reach the same SaveFile finding the File locked by the previous thread suspended
Here is a theory: your logging form is accessed through static variable. This variable is initialized on first access of the Log class, and this first access can happen from non-ui thread. So your form could be created on a non-ui thread, and this could cause the issues you are experiencing.
I figured out this problem with one of my friends.
Its actually because the mLogForm has never been showed before mLogForm.InvokeRequired is called. If its not showed, there will NEVER be a handle for mLogForm. Without handle, you will not be able to call mLogForm.InvokeRequired in its right way.
Which means it will return false even if other thread calls Log.Write
and then I got a lot threads running UpdateLog method, caused this problem.
To make sure you could use invoke to a unshowed form, use CreateHandle() while you create this form.
Thanks.
I am trying to figure out the best strategy for logging on the async-IO web server I am working on. I thought the easiest way was to have a singleton class that keeps Filestreams open for the appropriate log files so I could just do something like:
Util.Logger.GetInstance().LogAccess(str);
Or something like that.
My class looks like this:
public sealed class Logger {
private static StreamWriter sw;
private static readonly Logger instance = new Logger();
private Logger() {
sw = new StreamWriter(logfile);
}
public static Logger GetInstance() {
return instance;
}
public void LogAccess(string str) {
sw.WriteLine(str);
}
}
This is all just in my head really, and I'm looking for suggestions on how to make it better and also make sure I'm doing it properly. The biggest thing is I need it to be thread safe, which obviously it is not in its current state. Not sure of the best way to do that.
This is taken care of for you automatically if you use NLog - you define all of your loggers in a .config file and then you access all of them via the static LogManager class, which is a Singleton.
Here's an example which illustrates the thread-safe nature of NLog:
https://github.com/nlog/nlog/wiki/Tutorial#Adding_NLog_to_an_application
There's a method TextWriter.Synchronized which produces a thread-safe version of TextWriter. Try that.
a) Do not include "Log" in method names. It obvious that a logger logs. .Warning, .Error, etc are better method names since they describe which level the log entry has.
b) Create a background thread that writes to the log.
c) Enqueue entries from the logging methods and signal the worker thread.
d) Use (I don't know if I remember the method names correctly)
var methodInfo = new StackFrame(1).GetMethod();
var classAndMethod = methodInfo.DeclaringType.Name + "." + methodInfo.Name;
to get the calling method.
Doing that will give you only one thread that access the file.
Maybe you should try NLog or Log4net. Both of them are wonderful log framework.
But if you do want to write your own log component, Lock is a must when you output log messages.
It's common that buffering log messages in memory and write them to file once in a time.
Another framework that addreses these issues for you is the Object Guy's logging framework. It can optionally log in the background. Multiple threads can log to the same file. And multiple processes can log to the same file.
I don't think there's any simple way around locking if you want to write to the same file from multiple threads.
So the simple solution is to add a lock around any calls to the StreamWriter. Alternatively you could buffer the output in memory and only write it to the file once in a while which still requires locking, but the lock contention would be a lot lower. If you go to that length, though, you might as well go with a proper logging framework like log4net, which is thread-safe.
Or you could use a class with only shared methods..
Imports System.Threading
Public Class Logger
Private Shared ReadOnly syncroot As New Object
Public Shared Sub log(ByVal vInt As Integer)
ThreadPool.QueueUserWorkItem(New WaitCallback(AddressOf logThread), CStr(vInt))
End Sub
Public Shared Sub log(ByVal vStr As String)
ThreadPool.QueueUserWorkItem(New WaitCallback(AddressOf logThread), vStr)
End Sub
Private Shared Sub logThread(ByVal o As Object)
Dim str As String = CStr(o)
SyncLock syncroot
Using objWriter As New System.IO.StreamWriter(GetLogPath, True)
objWriter.WriteLine(str)
objWriter.Close()
End Using
End SyncLock
End Sub
Private Shared Function GetLogPath() As String
Return "logs.txt"
End Function
End Class
I found it more usable this way than using a singleton :
Logger.log("Something to log")
Cheers
I'm writing a console application which is looking up information about SSIS packages in SQL Server. I have it working and writing to a .csv file. I just added in the ability to pass command line switches for servername, foldername and outputfile. If an output file is not specified, I'd just like to output to the console, which I'm already doing.
The way I've handled the file writing seems awkward, and is probably wrong.
In my main method I create a StreamWriter. I need to write the entire output of the program to this file. I explore folders under my specified folder by recursively calling a function.
I pass the StreamWriter object along in all calls - it is a parameter in functions which don't use it, so it can be passed to the one that does. It seems like I should be able to make it a global variable, but I see that c# doesn't have globals and "if you are using a global, you are probably doing it wrong".
I'd planned on revisiting this issue eventually after plugging away at this little utility for a while, but I now have the problem that all the functions want the StreamWriter object - and if I make it optional, then it won't be there for the functions. And it also seems c# doesn't do optional arguments.
I'm sure you can tell I'm no c# expert and only dabble when I need to. Thanks for your assistance.
You want to use a singleton pattern to refer to the StreamWriter you're using. The singleton is a way to "simulate" the functionality of global variables, without having the problems of them.
Essentially, what the singleton provides is a class-specific instance of a resource you want to be shared among many different parts in your application. The resource is accessed through the a static class instance.
Effectively, what you'll want to do is to define a class which has as a public static member the StreamWriter that you'll want to use; in that way, any method that you use in the rest of your code can get access to that SAME instance of the StreamWriter by accessing it from the containing class (without needing to create an instance of the class, because it's static).
Something like
public static class CsvWriter
{
private static StreamWriter _writer = new StreamWriter(...);
public static StreamWriter Writer
{
get { return _writer; }
}
}
Some variation is possible, the main item is the static property here. It's like a global but not (entirely) as bad.
Are all the functions of the same class? You can make a class variable (a field) and access it from all the methods of the class. If not you can always create a new public class with a static field.
I you can use Console.SetOut for this:
static void Main(string[] args)
{
StreamWriter writer = new StreamWriter(#"c:\path\file.ext");
try
{
Console.SetOut(writer);
Console.WriteLine("One");
Console.WriteLine("Two");
Console.WriteLine("Three");
}
catch (Exception ex)
{
Console.WriteLine("That went wrong.");
}
finally
{
writer.Dispose();
}
}
I'm currently trying to write a thread-safe logger class. I'm not very familiar with correct design and best practices in this area. Is there a flaw in my code?
public class WriteStuff
{
private readonly StreamWriter m_Writer;
private readonly object m_WriteLock = new object ();
public WriteStuff(String path)
{
m_Writer = File.CreateText (path);
m_Writer.WriteLine ("x");
m_Writer.Flush ();
}
public void ListenTo(Foo foo)
{
foo.SomeEvent += new EventHandler<SomeArgs> (Foo_Update);
}
private void Foo_Update(object sender, SomeArgs args)
{
lock (m_WriteLock) {
m_Writer.WriteLine (args);
m_Writer.Flush ();
}
}
}
Well, that looks OK to me; I'd probably implement IDisposable as a means to Close() the file, but...
Of course, you could also use any of the (many) pre-canned logging frameworks.
Update:
One thought: you might want to consider what happens if the file already exists; you don't want to stomp on your logs...
What you've posted looks fine from a multi-threading perpective. Although I could be wrong, it would appear that any other code that does some multi-threading (even using the foo object) should be safe. Certainly, I can't see any deadlocks in the that section of code.
A few things worth noting anyway (apart from being very careful with deadlocks and testing rigourously to insure they won't occur):
It's best to put a lock around the code within the constructor, as I believe it's possible in certain circumstances that methods can be called before the constructor block has finished executing. (Someone please correct me if I'm wrong on this one.)
The StreamWriter object in this case is private, which is good. If it were protected or internal you would certainly have to be cautious about how other code utilised the object (in fact I think it would be best to almost always declare such objects as private).
You've done locking the right way! It's always safest to lock on a separate private instance object because you know that object can't be locked by any other code than your own (which isn't the case if you lock this or the StreamWriter object itself).
Still, I may be missing something, and there is a small possibility that some other code not shown above might cause problems, but as far as I can see it that code isn't flawed except for a possible missing lock around the constructor code. You're more likely to have to watch out for deadlock situations when you start doing more complex multi-threading, especially across classes/instances.
Anyway, hope that helps.
The event handler is on the same thread as the event generator which means your app could end up being held up by your log file write.
private void Foo_Update(object sender, SomeArgs args) {
ThreadPool.QueueUserWorkItem(WriteAsync, args);
}
private void WriteAsync(object state) {
SomeArgs args = (SomeArgs)state;
lock (m_WriteLock) {
m_Writer.WriteLine (args);
m_Writer.Flush ();
}
}