logging-log4net-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel Marohn" <mar...@sipgate.de>
Subject Re: Multi-app centralized logging vs. per app logging and background process consolidation
Date Mon, 11 Feb 2008 07:23:29 GMT
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

Mime
View raw message