I have done performance tests but in win32 C++ environment and synchronization on heavy load was issue. Problem is that I need log lot of data, for example input and output parameters of each web service method call.
Thanks for suggestion howto rewrite log4j. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, January 08, 2004 5:16 PM To: Log4J Users List Subject: RE: EJB and Log4J How stringent is your requirement to avoid synchronization? In practice, I have found that logging with log4j has no significant performance impact on app-server performance. And remember that with modern JVM's, synchronization is quite cheap unless there is actual contention between threads. Unless you're using your log system to doing very fine-grain tracing, no logging system should cause you problems here. I'd recommend you run some performance tests to verify whether this is really a serious issue for your system. If it really is a serious issue, then, from my appraisal of the 1.2.8 source-code, you should be able to address the issue fairly easily. Writing a minimally-synchronized file-per-thread Appender shouldn't be too hard. And the only mods to the core of log4j would be to replace the synchronized blocks in Category.callAppenders, Category,addAppender, Category.removeAppender, Category.getAllAppenders, Category.getAppender, and Category.removeAllAppenders with a shared read-lock/exclusive write-lock mechanism. You may also want to replace the Vector in org.apache.log4j.helpers.AppenderAttachableImpl with an ArrayList. This should be a trivial task, especially compared to writing your own log system. Ant it should eliminate almost all logging-related synchonization overhead. FYI if you're interested in doing this, Doug Lea has some good code examples of read/write locking in his book "Concurrent Programming in Java: Design Principles and Patterns". --Ian --- Mas�r_Daniel <[EMAIL PROTECTED]> wrote: > Thanks to all for valuable comments. > Now I know what is behind mentioned constraint. > In my case i can safely wrote files from EJB. > > Another thing: main goal of my logging solution is to don't serialize > clients on log write operation. I want to create as many parallel log > files as many concurrent client threads can be on EJB layer and reuse > log files. As wrote Ingo lot of calls on log4j is serialized. So it > seems that without rewrite of core components of log4j I don't know to > avoid synchornization (sure there have to be some minimal > synchornization)? > > Daniel Masar > > -----Original Message----- > From: Ingo Adler [mailto:[EMAIL PROTECTED] > Sent: Wednesday, January 07, 2004 9:53 PM > To: Log4J Users List > Subject: Re: EJB and Log4J > > donald larmee|ALTERthought wrote: > > >As Michael indicated, it is generally an accepted practise to ignore > > >this aspect of the J2EE spec (for example, jboss usese log4j and > >regularly writes flat log files...) > > > > > > > > An application server (like JBoss) may use files or anything else it > needs. The spec is about the applications running inside the > application server. > > Nevertheless, the problem is not the usage of files, the problem is > the synchronization which is done by log4j independent of the > appender. > Every call to a logger and most of the calls to an appender (derived > from AppenderSkeleton) are synchronized. > > If you use the FileAppender anyway, don't write to the same file from > different nodes in a clustered environment. > > Ingo. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
