Hi, Please find below a webrev for:
8029281: Synchronization issues in Logger and LogManager <https://bugs.openjdk.java.net/browse/JDK-8029281: I believe this changeset will also fix JDK-8027670 and JDK-8029092 - which I have thus closed as duplicates of JDK-8029281. webrev: <http://cr.openjdk.java.net/~dfuchs/webrev_8029281/webrev.00/> Now some comments on the fix: LogManager: When a logger was garbage collected, and then a new logger of the same name requested, addlocalLogger used to call LoggerContext.removeLogger to remove the stale reference and replace it by a new one. But sometime, the stale reference was still in the reference queue, which caused the *new* logger to be wrongly removed later when the reference queue was drained. LogManager was also missing some synchronization for its 'props' variable. Logger: userBundle & resourceBundleName were sometimes accessed within a synchronized block, and sometimes without. In particular the getters were not synchronized, which could cause race conditions because an other thread could see inconsistent data. I also had to refactor the two methods getEffectiveResourceBundle() and getResourceBundleName() into a single method. The code there might be a bit more difficult to follow, because I made sure it preserved the former behavior wrt to what will be set in the LogRecord in doLog(). Tests: The new TestLoggerBundleSync.java has been great to test the issues above in both Logger & LogManager (it detected the drainLoggerRefQueueBounded issue). Since I had to touch at drainLoggerRefQueueBounded to make TestLoggerBundleSync.java pass I also threw in a TestLogConfigurationDeadLock.java to make sure I hadn't introduced any new deadlock (and it detected the lack of synchronization in LogManager.props). best regards, -- daniel