A lot of what you describe is available in the AsyncAppender. I recommend buffering log events before sending them to the AsyncAppender so each async thread holds more than just one event:
BufferingForwardingAppender -> AsyncAppender -> AdoNetAppender You should see performance gains even with a small buffer of 5 or 10 events. ----- Original Message ---- From: Daniel Marohn <[EMAIL PROTECTED]> To: Log4NET User <[email protected]> Sent: Monday, February 11, 2008 2:23:29 AM Subject: Re: Multi-app centralized logging vs. per app logging and background process consolidation Hey Dave! message to a local queue. A service on each host then processes these messages (using log4net again) and logs them to a central database Do you have the time, beeing a bit more specific here? Is this service independed from the application, or do it holds references to logging application's dlls? In other words: Are you using the same generic service for all remote applications, or a customized version for every single one? What kind of objects do you log into the queue? strings, perhaps xml? or real bussiness (message) objects? Do the service hold any logic, or is it only getting msgs from queue and (without looking inside) forwarding to ado? As far as I can see, the only thing you win here, is some kind of async logging. The price you have to pay is an extra level in your design (the service), and your app depends on an additional tech (msmq). If the only think you want, is a non-blocking app and it's ok if msgs will be logged in possible wrong order as long as the timestamp shows the real date, you can simply do this: Build your own depender, following the decorator pattern. The new appender holds a property, referencing to the real appender (ado-appender in this case). Every time the appender is asked to logg a new message, it creates a new thread, starts it and leave. Inside the new thread the recieved msg is passed to the real appender (less than 20 lines of code for whole appender). So every logginrequest is aync, and I guess creating a new thread is even faster, than writing to msmq. Plus: you can add additional logic inside the decorator (wait with writing to db as long as x msgs recieved; using a threadpool; store msgs as long as network is unavailable; or whatever), and use this in other apps, becourse its totaly independend from rest off your app (I guess I would put it inside an independed dll). And: Of course the appender itself can be reused with other appenders than ado. It simply adds asynfunctionality to every appender you choose. Daniel
