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 ------- Additional Comments From [EMAIL PROTECTED] 2005-12-03 23:03 ------- My unsubstantiated opinion is that the proposed solution would break the locking contract so it can't be addressed in a 1.x branch. >From what I can tell, the observed problem is not a regression. The coarse-grain locking approach has been in log4j likely forever. The problem only manifests itself when you pass an Object (not a String) as the message and the toString() method itself logs or otherwise acquires a lock on a log4j object. If the developer does not pass objects or only pass objects where he knows that toString() does not acquire locks, the problem does not occur. If a lock is released to allow a locking toString() to be called, all the potential code paths that might be executed (possibly including custom appenders and layouts) must be audited to see if their will be any interaction between the in-process logging request and logging requests that may be called in the toString() call or if the release of the lock might allow any other logging request to enter the pipeline while the original request is suspended. Much of the log4j internals aren't thread safe by themselves and depend on the outer synchronization to keep things safe. Another approach would be to use a thread with a timeout to call toString(). If the call blocked, then some message like "Message unavailable timeout while calling CLASSNAME.toString() " could be created. It would add overhead to any call where msg is not a String and all the preconditions are satisified, however that may not be high relative to the processing cost of most appenders. -- 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]
