glassfish
  1. glassfish
  2. GLASSFISH-20541

LogManagerService synchronization causes potential deadlock

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: 4.1
    • Fix Version/s: None
    • Component/s: logging
    • Labels:
      None

      Description

      The LogManagerService.postConstruct code contains the following:

      synchronized(java.util.logging.Logger.class){
      synchronized (logMgr) {
      ...

      There is a comment around this code that refers to this fixing a deadlock. See GLASSFISH-7274.

      However, this code is generally making the assumption that synchronizing on the LogManager will allow this method to make changes to all of the Loggers being managed by the LogManager without any new Loggers being added to the LogManager in another thread. The java.util.logging code does not guarantee that. In fact, it doesn't guarantee anything about what happens if you lock the LogManager object. And in JDK 1.7_21, you get a deadlock if the LogManager is locked while another thread calls Logger.getLogger.

      The fix for this will require changing the GlassFish logging service so that it doesn't make this assumption. For example, it may have to implement its own LogManager rather than using the system one.

      This issue is related to GLASSFISH-20299. When the ResourceManager service is moved to run level "Init" so that it runs at the same time as the LogManagerService initialization, then a deadlock can be observed between these two threads.

        Issue Links

          Activity

          Hide
          sandeep.shrivastava added a comment -

          The code to synchronize on the Logger class and then acquire a lock on the LogManager is there to prevent a deadlock situation described in https://java.net/jira/browse/GLASSFISH-7274

          Logger.getLogger() is a synchronized static method which tries to get a LogManager lock. Synchronized methods in the LogManager class tries to get a lock on the Logger class which can lead to a deadlock hence the LogManagerService tries to synchronize on the Logger class and then invokes synchronous operations on the LogManager.

          Also since the potential deadlock stack trace is not supplied, we are not addressing this issue at this point.

          Show
          sandeep.shrivastava added a comment - The code to synchronize on the Logger class and then acquire a lock on the LogManager is there to prevent a deadlock situation described in https://java.net/jira/browse/GLASSFISH-7274 Logger.getLogger() is a synchronized static method which tries to get a LogManager lock. Synchronized methods in the LogManager class tries to get a lock on the Logger class which can lead to a deadlock hence the LogManagerService tries to synchronize on the Logger class and then invokes synchronous operations on the LogManager. Also since the potential deadlock stack trace is not supplied, we are not addressing this issue at this point.

            People

            • Assignee:
              sandeep.shrivastava
              Reporter:
              Tom Mueller
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: