Reputation: 4009
It's not really a coding problem, but i'm after some feedback from the community regarding some issues that I'm having, while developing a new Logger implementation.
our ASP.NET Application originally worked with log4net. While log4net is a great logging tool, it does not suit our needs and in some cases it even causes problems for our application by the way the logging is done. We currently are implementing our own logging system that is mimicing some behavior of log4net, but also tailored to suit our needs. I'm not here to discuss about the usage of log4net or how to config it.
Currently we have a system that's beeing developed. The system has a logger class, which is a Singleton (design flaw, I know...) and this class has a collection of IReporter objects.
Everytime the application calls Logger.Instance.Log(message) the logger will direct these messages to every IReporter inside the queue, and the reporters have the responsibility of logging the message in their destination/storage/whatever.
Currently we've chosen that each IReporter has a backgroundthread and a message queue to process the messages at their own speed. The danger here is that when the app dies suddenly we could lose some of the messages.
Another approach we had in mind was to have a thread pool on the logger and let these threads run over the queue and then delegate the messages to the reporters.
What I'm concerned about is the performance. We first implemented this using events in the logger, but the threads spawned went haywire fast when accessing the file. So now with this approach we hope to limit the access to the resources
What I'm lookign for is people who had similar situations and how they approached this issue.
Upvotes: 1
Views: 442
Reputation: 9569
Your design sounds an awful lot like Log4Net with a bunch of FileAppender
s. You should really reconsider your decision, unless there are requirements on you that you haven't shared. Log4Net has a lot more use in the field than your logger ever will, and it's had lots of bugs and performance issues already shaken out of it.
Upvotes: 0
Reputation: 165
Did I understand it correctly, and all those processes access the same set of files? On Windows?
You shouldn't do that, as the OS will do some complex locking that will take time, or worse, depending on how you access the files, you can get a deadlock. It would be better to do all the logging on one single thread, and running the IReporters sequentialy.
If you are concerned that your software may die during a log operation, put the logger in another process, communicate by IPC. But are you sure you want to reinvent syslogd?
Upvotes: 2