DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=24159>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=24159 [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |ASSIGNED ------- Additional Comments From [EMAIL PROTECTED] 2005-12-04 02:22 ------- Although the *first* comments were suggesting changing AppenderSkeleton, I have been suggesting in the later comments an alternative solution that does not break compatibility. I offer the following suggestion: Maintain the existing appender class tree as-is. Introduce a new package called org.apache.log4j.concurrent which contains deadlock-free and concurrent appenders. (These are within an attachment to this bug, I also have newer versions to offer which have several tweaks.) Make any new 1.3 appenders (e.g. "log4j.rolling.RollingFileAppender") derive from log4j.concurrent.FileAppender. Make the new org.apache.log4j.pattern.PatternConverter thread-safe. (All of them for 1.3 are, except the DatePatternConverter.) Although "Layout" does not indicate thread usage pattern, by convention it appears thread-unsafe. I suggest that you fix it by stating that implementations must be thread-safe and fix the log4j implementations to match. (Alternatively, assume that this class must be externally locked. This increases the locking scope for all usages, although locking may not be necessary.) (Note that string buffer reuse does not help performance for mature JVM versions.) Advantages: Synchronization convention guaranteed for users who derive from existing appender classes. Provides a standard implementation base for application servers, such as JBoss and Tomcat. Disadvantages: Existing appender classes are "mirrored" and increase maintenence cost. Additional code bloat. (Note: If the classes in this package are not used, there is no memory impact.) * Note: There may be some possible way to create an AppenderSkeleton that uses two different locking strategies, which are configured by system property, a configuration key, or by class name. You would want to have any subclass implementation by default use the original locking strategy. I considered this approach, but I thought it better to clean up the existing AppenderSkeleton ugliness instead. * Note: If somebody would allow it, I would like to have repository access so that I may check-in and maintain the classes properly myself. I'm not sure what the secret handshake is, but I have repository access for some other open projects, so I believe I'm generally trustworthy. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
