You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by "Ralph Goers (JIRA)" <ji...@apache.org> on 2010/05/15 09:01:44 UTC
[jira] Commented: (LOG4J2-3) Minimal (aka fine grained) locking
[ https://issues.apache.org/jira/browse/LOG4J2-3?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12867821#action_12867821 ]
Ralph Goers commented on LOG4J2-3:
----------------------------------
In my experimental branch java.util.concurrent is used quite a bit. Locking is as minimal as possible.
> Minimal (aka fine grained) locking
> ----------------------------------
>
> Key: LOG4J2-3
> URL: https://issues.apache.org/jira/browse/LOG4J2-3
> Project: Log4j 2
> Issue Type: Wish
> Components: Core
> Reporter: Curt Arnold
>
> Most components of log4j 1.2 are not inherently thread-safe but depend on locks that are acquired after the threshold check and are not released until processing is completed. Unless the AsyncAppender is used, this effectively limits log4j 1.2 to handlng only one logging request at a time.
> Core classes in log4j 2.0 should not depend on external synchronization for thread safety.
> Immutable classes should be preferred in the logging pipeline.
> Class attributes (aka @Immutable and @ThreadSafe) should be used to document thread-safety.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org