-
Bug
-
Resolution: Fixed
-
P3
-
6u11
-
b108
-
x86
-
windows_xp
-
Not verified
FULL PRODUCT VERSION :
java version "1.6.0_11"
Java(TM) SE Runtime Environment (build 1.6.0_11-b03)
Java HotSpot(TM) Client VM (build 11.0-b16, mixed mode, sharing)
ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows XP [Version 5.1.2600]
A DESCRIPTION OF THE PROBLEM :
java.util.logging.Logger's javadocs thoughtfully state that "All methods on Logger are multi-thread safe. "
Unfortunately, the javadocs for java.util.logging.Handler are completely silent on this issue. This is in itself a bug: the javadocs need to state one way or the other whether or not Handlers are expected to be thread safe.
Looking at the source code for Handler (and its subclasses) reveals something disturbing: two of its methods (setLevel and getLevel) are synchronized, but all the other methods are unsynchronized. However, those methods usually involve shared mutable state. For instance, getFilter/setFilter, getEncoding/setEncoding, etc.
It is the case that Handler's mutators call its checkAccess method which makes a call to LogManager's checkAccess method which may make a call to System.getSecurityManager() which involves the volatile security field of System, so a weak "happens-before" relationship is currently being established by Handler's mutators.
However, it is not clear at all if this "happens-before" relationship is used in some clever way to achieve thread safety, or if it is an accident. It needs to be carefully documented if so.
Actually, this "happens-before" relationship does nothing to guarantee visibility of changes by the mutator methods for subsequent calls to the corresponding accessor methods. For memory visibility purposes, you need some sort of synchronization for BOTH the accessors and mutators. SO, the current implementation does seem to be buggy.
The easiest fix for all these issues would be to synchronize all the public methods of every handler class, and javadoc that this is the policy.
Not knowing your thread safety policies for Handlers makes it extremely difficult for me to properly subclass Handler (I will be filing a RFE with you shortly regarding a proposed replacement for ConsoleHandler--stay tuned).
REPRODUCIBILITY :
This bug can be reproduced always.
java version "1.6.0_11"
Java(TM) SE Runtime Environment (build 1.6.0_11-b03)
Java HotSpot(TM) Client VM (build 11.0-b16, mixed mode, sharing)
ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows XP [Version 5.1.2600]
A DESCRIPTION OF THE PROBLEM :
java.util.logging.Logger's javadocs thoughtfully state that "All methods on Logger are multi-thread safe. "
Unfortunately, the javadocs for java.util.logging.Handler are completely silent on this issue. This is in itself a bug: the javadocs need to state one way or the other whether or not Handlers are expected to be thread safe.
Looking at the source code for Handler (and its subclasses) reveals something disturbing: two of its methods (setLevel and getLevel) are synchronized, but all the other methods are unsynchronized. However, those methods usually involve shared mutable state. For instance, getFilter/setFilter, getEncoding/setEncoding, etc.
It is the case that Handler's mutators call its checkAccess method which makes a call to LogManager's checkAccess method which may make a call to System.getSecurityManager() which involves the volatile security field of System, so a weak "happens-before" relationship is currently being established by Handler's mutators.
However, it is not clear at all if this "happens-before" relationship is used in some clever way to achieve thread safety, or if it is an accident. It needs to be carefully documented if so.
Actually, this "happens-before" relationship does nothing to guarantee visibility of changes by the mutator methods for subsequent calls to the corresponding accessor methods. For memory visibility purposes, you need some sort of synchronization for BOTH the accessors and mutators. SO, the current implementation does seem to be buggy.
The easiest fix for all these issues would be to synchronize all the public methods of every handler class, and javadoc that this is the policy.
Not knowing your thread safety policies for Handlers makes it extremely difficult for me to properly subclass Handler (I will be filing a RFE with you shortly regarding a proposed replacement for ConsoleHandler--stay tuned).
REPRODUCIBILITY :
This bug can be reproduced always.