Our company has adopted log4j and quite frankly, love it. I've only gotten positive feedback for making the decision to migrate to log4j. We have been using it as designed, for logging/tracing and performance has not been an issue since there are virtually no log records being written in a production environment except for the occasional warning or error.
However, I have been tasked with the job of creating a auditing service which will be somewhat volumous depending on what is going on. My initial thought was to create an auditing API and delegate the details to log4j but was concerned about potential scalability issues with the synchronization of the handlers. It is obvious to us that volumous logging takes a finite amount of time and the more auditing that has to be done, the slower the application is going to be. My real concern is in a web or ejb container that creates multiple object instances that must be "single-threaded" though a synchronization block in an appender. An analogy would be a datasource connection. We would not want every client to access a datasource through a single connection, so we create connection pools to help elevate the scaling issues. I would think synchronized appenders would be a similar concern for others as well. If you have any experience or comments about this, I would very much appreciate it. Thanks, Bill ps. I'm sure this has been discussed before and have searched the archives but never found the discussion I was looking for. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
