glassfish
  1. glassfish
  2. GLASSFISH-18336

Error starting remote, SSH instance after changing all log levels

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: 3.1.2_b21
    • Fix Version/s: future release
    • Component/s: logging
    • Labels:
      None
    • Environment:

      DAS on OEL 6 with JDK 7u3, b04
      remote instance on Solaris 10 with JDK 7u3, b04
      Firefox on Winxp

      Description

      After changing all log levels for a remote instance, on SSH node, to WARNING, instance fails to start with the following error in Admin Console:

      An error has occurred
      Could not start instance intp on node tuppy (tuppy). Command failed on node tuppy (tuppy): CLI801 Instance is already synchronized Waiting for intp to start ..........Command start-local-instance failed. Error starting instance intp. The server exited prematurely with exit code 1. Before it died, it produced the following output: Launching GlassFish on Felix platform Completed shutdown of GlassFish runtime Exception in thread "main" java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at com.sun.enterprise.glassfish.bootstrap.GlassFishMain.main(GlassFishMain.java:97) at com.sun.enterprise.glassfish.bootstrap.ASMain.main(ASMain.java:55) Caused by: java.lang.NullPointerException at com.sun.enterprise.server. .... msg.seeServerLog

      Attaching server.log files.

      I have tried it several times with b20 and b21 and it always happens in my setup with a remote instance on an SSH node. I does not happen when instance is on a DCOM node or on localhost. Changing just one or two log levels for an instance on SSH node does NOT trigger this error. However, I'm still logging this as a Major issue, so we at least investigate it, since this is not an unlikely scenario, to set all log levels to warning on a production system.

      Steps to reproduce:

      1. Create a remote SSH node.
      2. Create a standalone instance under the new node and start it.
      3. In Admin Console go to instance's configuration, Logger Settings, Log Levels.
      4. Select checkboxes for all loggers, WARNING for Log Level drop down and click on Change Level. Then click on Save.
      5. Go back to instance page and stop it.
      6. Start the instance and the above mentioned error is displayed.

      1. logging.properties.das.txt
        4 kB
        lidiam
      2. logging.properties.instance.txt
        1 kB
        lidiam
      3. LoggingHandlers.diff.text
        3 kB
        Anissa Lam
      4. server.log.badfileexception.txt
        19 kB
        lidiam
      5. server.log.das.txt
        26 kB
        lidiam
      6. server.log.instance.txt
        9 kB
        lidiam
      1. error-starting-instance.JPG
        115 kB
      2. logging-error-saving-changes.JPG
        88 kB

        Activity

        Hide
        lidiam added a comment -

        Once I change log levels to INFO for all loggers, and set com.sun.enterprise.server.logging.GFFileHandler level to ALL, instance starts fine once again. However, if I only change all log levels to INFO, instance still fails to start with the same exception. Please note that there is no "Load Default" button on this page, so user will have hard time finding out what were the default settings (it can be seen in default-conifg).

        Show
        lidiam added a comment - Once I change log levels to INFO for all loggers, and set com.sun.enterprise.server.logging.GFFileHandler level to ALL, instance starts fine once again. However, if I only change all log levels to INFO, instance still fails to start with the same exception. Please note that there is no "Load Default" button on this page, so user will have hard time finding out what were the default settings (it can be seen in default-conifg).
        Hide
        naman_mehta added a comment -

        As per the error looks like logging.properties files are missing some entries on SSH node.

        Can you send me logging.properties files from ssh machine?
        Have you changed log levels through admin console?
        Can you share same machine with me so I can check the same?

        Show
        naman_mehta added a comment - As per the error looks like logging.properties files are missing some entries on SSH node. Can you send me logging.properties files from ssh machine? Have you changed log levels through admin console? Can you share same machine with me so I can check the same?
        Hide
        lidiam added a comment -

        Attaching logging.properties.instance.remote.txt file - this is logging.properties file on the remote SSH node, under <glassfish home>/glassfish/nodes/tuppy/intp/config/intp-config directory.

        Show
        lidiam added a comment - Attaching logging.properties.instance.remote.txt file - this is logging.properties file on the remote SSH node, under <glassfish home>/glassfish/nodes/tuppy/intp/config/intp-config directory.
        Hide
        lidiam added a comment -

        I performed all operations from Admin Console, as described in steps to reproduce section. I attached logging.properties for the instance on the remote SSH node - the file is the same as on the DAS system, under domain1/config/intp-config (diff shows no difference). I also sent you an email with the machine information.

        Show
        lidiam added a comment - I performed all operations from Admin Console, as described in steps to reproduce section. I attached logging.properties for the instance on the remote SSH node - the file is the same as on the DAS system, under domain1/config/intp-config (diff shows no difference). I also sent you an email with the machine information.
        Hide
        naman_mehta added a comment -

        logging.properties file is correct...

        Have you changed log levels through admin console? Can you share same machine with me so I can check the same? Is it reproducible/occasionally?

        Show
        naman_mehta added a comment - logging.properties file is correct... Have you changed log levels through admin console? Can you share same machine with me so I can check the same? Is it reproducible/occasionally?
        Hide
        lidiam added a comment -

        I have changed the log levels back to info, in order to see if instance would start then. I already wrote that all operations were performed through Admin Console, including setting the log levels. Please see the section above that starts with "Steps to reproduce". It is reproducible each time all log levels are set to WARNING.

        Show
        lidiam added a comment - I have changed the log levels back to info, in order to see if instance would start then. I already wrote that all operations were performed through Admin Console, including setting the log levels. Please see the section above that starts with "Steps to reproduce". It is reproducible each time all log levels are set to WARNING.
        Hide
        naman_mehta added a comment -

        I tried on my local machine with use of ssh node on another machine on linux but couldn't able to reproduce the same. I tried several times but no success.

        Then, I tried on same machine and same setup having this issue filed but after several runs it couldn't be reproducible.

        Show
        naman_mehta added a comment - I tried on my local machine with use of ssh node on another machine on linux but couldn't able to reproduce the same. I tried several times but no success. Then, I tried on same machine and same setup having this issue filed but after several runs it couldn't be reproducible.
        Hide
        naman_mehta added a comment -

        Lidia,

        Please try yourself again on same machine by creating new node and new instance. If it's reproducible for you then stop using this machine. Let me know, I will debug same on this machine only by doing remote debug.

        Show
        naman_mehta added a comment - Lidia, Please try yourself again on same machine by creating new node and new instance. If it's reproducible for you then stop using this machine. Let me know, I will debug same on this machine only by doing remote debug.
        Hide
        naman_mehta added a comment - - edited

        I would able to identify the issue: Sometimes logging.properties file is missing entries

        Initially logging.properties file contains:
        "logging.properties" 69 lines, 3756 characters

        now after updating log levels from admin console
        "logging.properties" 46 lines, 2285 characters

        So missing some properties which is causing failure....

        Show
        naman_mehta added a comment - - edited I would able to identify the issue: Sometimes logging.properties file is missing entries Initially logging.properties file contains: "logging.properties" 69 lines, 3756 characters now after updating log levels from admin console "logging.properties" 46 lines, 2285 characters So missing some properties which is causing failure....
        Hide
        naman_mehta added a comment -

        When you change log levels through admin console it's going to update logging.proeprties file on DAS and then trying to replicate on the instance machine. But sometimes we are stopping instance before replication is successful and which corrupts the logging.properties file on remote machine. If you check logging.properties file on DAS it's up to date and corrupted on remote machine.

        Now, next time when you trying to start instance it's looking for some properties on startup and which are missing there and so it's not coming up.

        Solution is to to avoid catastrophic failure in the absence of a user defined configuration property like com.sun.enterprise.server.logging.GFFileHandler.file.

        Show
        naman_mehta added a comment - When you change log levels through admin console it's going to update logging.proeprties file on DAS and then trying to replicate on the instance machine. But sometimes we are stopping instance before replication is successful and which corrupts the logging.properties file on remote machine. If you check logging.properties file on DAS it's up to date and corrupted on remote machine. Now, next time when you trying to start instance it's looking for some properties on startup and which are missing there and so it's not coming up. Solution is to to avoid catastrophic failure in the absence of a user defined configuration property like com.sun.enterprise.server.logging.GFFileHandler.file.
        Hide
        lidiam added a comment -

        I tried the following on newly created instance:

        1. Changed all log levels to WARNING, waited 25 seconds after Admin Console reported logging changes saved.
        Result: instance started fine.

        2. Changed all log levels to INFO, waited 20 seconds after Admin Console reported logging changes saved.
        Result: instance started fine.

        3. Chagned all log levels to SEVERE - could not save the change with the following error in Admin Console:

        An error has occurred
        An error occurred during replication Failure: Command set-log-levels failed on server instance inbif: remote failure: Could not set logger levels for inbif-config. Failure: Command set-log-levels failed on server instance inbif: remote failure: Could not set logger levels for inbif-config.

        The following exception was in the instance's server.log:

        [#|2012-02-08T15:05:16.277-0800|SEVERE|oracle-glassfish3.1.2|null|ThreadID=19;
        ThreadName=Thread-2;|Cannot read logging.properties file :
        java.io.IOException: Bad file number
        at java.io.FileInputStream.readBytes(Native Method)

        I'm attaching instance's server.log as server.log.badfileexception.txt.

        Show
        lidiam added a comment - I tried the following on newly created instance: 1. Changed all log levels to WARNING, waited 25 seconds after Admin Console reported logging changes saved. Result: instance started fine. 2. Changed all log levels to INFO, waited 20 seconds after Admin Console reported logging changes saved. Result: instance started fine. 3. Chagned all log levels to SEVERE - could not save the change with the following error in Admin Console: An error has occurred An error occurred during replication Failure: Command set-log-levels failed on server instance inbif: remote failure: Could not set logger levels for inbif-config. Failure: Command set-log-levels failed on server instance inbif: remote failure: Could not set logger levels for inbif-config. The following exception was in the instance's server.log: [#|2012-02-08T15:05:16.277-0800|SEVERE|oracle-glassfish3.1.2|null| ThreadID=19; ThreadName=Thread-2;|Cannot read logging.properties file : java.io.IOException: Bad file number at java.io.FileInputStream.readBytes(Native Method) I'm attaching instance's server.log as server.log.badfileexception.txt.
        Hide
        lidiam added a comment -

        It looks like stopping of the instance is NOT the cause of bad logging.properties file being written to the remote machine. This looks like an intermittent problem with writing full logging.properties file to the remote machine. Once the "bad" file is written, I can wait for a minute before restarting server and it is not getting corrected. Here is what I tested:

        1. Change all log levels and save.
        2. Wait 30 seconds after save.
        3. Compare size of logging.properties files on DAS and remote system.
        4. Restart instance.

        While executing the above, logging.properties file got corrupted on the 4th attempt - size differed between DAS and remote and instance failed to start. I tested further and again hit the issue on the 6th attempt (or 10th, 4 + 6 new attempts). The trouble is that once the instance cannot be started I can only fix it by manually copying logging.properties file from DAS to the instance. Other changes, also to logging properties, don't seem to trigger copying the file over.

        Show
        lidiam added a comment - It looks like stopping of the instance is NOT the cause of bad logging.properties file being written to the remote machine. This looks like an intermittent problem with writing full logging.properties file to the remote machine. Once the "bad" file is written, I can wait for a minute before restarting server and it is not getting corrected. Here is what I tested: 1. Change all log levels and save. 2. Wait 30 seconds after save. 3. Compare size of logging.properties files on DAS and remote system. 4. Restart instance. While executing the above, logging.properties file got corrupted on the 4th attempt - size differed between DAS and remote and instance failed to start. I tested further and again hit the issue on the 6th attempt (or 10th, 4 + 6 new attempts). The trouble is that once the instance cannot be started I can only fix it by manually copying logging.properties file from DAS to the instance. Other changes, also to logging properties, don't seem to trigger copying the file over.
        Hide
        lidiam added a comment -

        I'm attaching logging.properties files from the time of failure:

        t# ls -l logging.p*
        rw-rr- 1 j2eetest green 3659 Feb 8 15:36 logging.properties.das
        rw-rr- 1 j2eetest green 1278 Feb 8 15:36 logging.properties.instance

        Show
        lidiam added a comment - I'm attaching logging.properties files from the time of failure: t# ls -l logging.p* rw-r r - 1 j2eetest green 3659 Feb 8 15:36 logging.properties.das rw-r r - 1 j2eetest green 1278 Feb 8 15:36 logging.properties.instance
        Hide
        lidiam added a comment -

        Example of error in Admin Console when logging changes cannot be saved due to corrupted logging.properties file.

        Show
        lidiam added a comment - Example of error in Admin Console when logging changes cannot be saved due to corrupted logging.properties file.
        Hide
        lidiam added a comment -

        Attaching logging.properties files with txt extension for easier viewing.

        Show
        lidiam added a comment - Attaching logging.properties files with txt extension for easier viewing.
        Hide
        Joe Di Pol added a comment -

        Workaround is to manually copy the logging.properties from the DAS to the instance that can't start.

        Show
        Joe Di Pol added a comment - Workaround is to manually copy the logging.properties from the DAS to the instance that can't start.
        Hide
        naman_mehta added a comment -

        set-log-level command has capability to update multiple log levels simultaneously.

        Usage of command:
        ./asadmin set-log-levels --target in5-config javax.enterprise.system.container.cmp=INFO:javax.enterprise.resource.webcontainer.jsf.application=INFO:javax.enterprise.system.ssl.security=INFO

        Here, all logger name are : separated.

        In this scenario, logging back end code will open logging.properties files once update all log levels as passed and closing logging.properties file. So here all log levels are updated in single file operation.

        --------------------------------------------------------------------------------------------------------

        In current scenario, when user updates all log level through admin console by selecting all logger names, it passes single logger name and log level to back end code then next time passes another logger name and log level. So if glassfish has 46 loggers it has 46 back end calls and due to that file operation is also becomes multiple of 46 and which causes file related exception in back end code.

        Instead of this admin gui can consolidate all log levels with : separated as above and pass to back end code which cause single file operation and it avoids file related exceptions.

        Show
        naman_mehta added a comment - set-log-level command has capability to update multiple log levels simultaneously. Usage of command: ./asadmin set-log-levels --target in5-config javax.enterprise.system.container.cmp=INFO:javax.enterprise.resource.webcontainer.jsf.application=INFO:javax.enterprise.system.ssl.security=INFO Here, all logger name are : separated. In this scenario, logging back end code will open logging.properties files once update all log levels as passed and closing logging.properties file. So here all log levels are updated in single file operation. -------------------------------------------------------------------------------------------------------- In current scenario, when user updates all log level through admin console by selecting all logger names, it passes single logger name and log level to back end code then next time passes another logger name and log level. So if glassfish has 46 loggers it has 46 back end calls and due to that file operation is also becomes multiple of 46 and which causes file related exception in back end code. Instead of this admin gui can consolidate all log levels with : separated as above and pass to back end code which cause single file operation and it avoids file related exceptions.
        Hide
        naman_mehta added a comment -

        One more thing I monitored,

        If user changes single log level for admin console then also it passes all logger names and levels to the back end code.

        So for single log level updates from GUI also making 46 back end calls to set-log-level command.

        Show
        naman_mehta added a comment - One more thing I monitored, If user changes single log level for admin console then also it passes all logger names and levels to the back end code. So for single log level updates from GUI also making 46 back end calls to set-log-level command.
        Hide
        Rebecca Parks added a comment -

        Added to the 3.1.2 Release Notes:

        Description

        Changing all log levels on a remote SSH server instance before stopping the instance can cause the instance to fail to restart.

        Workaround

        Manually copy the logging.properties file from the domain administration server (DAS) to the server instance that won’t restart.

        Show
        Rebecca Parks added a comment - Added to the 3.1.2 Release Notes: Description Changing all log levels on a remote SSH server instance before stopping the instance can cause the instance to fail to restart. Workaround Manually copy the logging.properties file from the domain administration server (DAS) to the server instance that won’t restart.
        Hide
        lidiam added a comment -

        Now that this issue is understood fully I'm upgrading it to P2, after talking to Sudipa. Since logging.properties file is relatively likely to get corrupted, we should fix this issue for 3.1.2 if another show stopper is found for this release. I'm also reassigning to Admin Console, to evaluate the possible fix proposed by Naman.

        Show
        lidiam added a comment - Now that this issue is understood fully I'm upgrading it to P2, after talking to Sudipa. Since logging.properties file is relatively likely to get corrupted, we should fix this issue for 3.1.2 if another show stopper is found for this release. I'm also reassigning to Admin Console, to evaluate the possible fix proposed by Naman.
        Hide
        Anissa Lam added a comment -

        Agree that GUI shouldn't call changing of one log level at a time. Thats bad for performance too. I have fixed that in the trunk for 4.0

        Log Message:
        ------------
        Improve performance of GUI when changing log levels and to work around a bug in logging, GLASSFISH-18336
        Revisions:
        ----------
        52523
        Modified Paths:
        ---------------
        trunk/main/appserver/admingui/common/src/main/java/org/glassfish/admingui/common/handlers/LoggingHandlers.java

        I am attaching the diff for 3.1.2 in case management believe this needs to be in 3.1.2 too.

        Show
        Anissa Lam added a comment - Agree that GUI shouldn't call changing of one log level at a time. Thats bad for performance too. I have fixed that in the trunk for 4.0 Log Message: ------------ Improve performance of GUI when changing log levels and to work around a bug in logging, GLASSFISH-18336 Revisions: ---------- 52523 Modified Paths: --------------- trunk/main/appserver/admingui/common/src/main/java/org/glassfish/admingui/common/handlers/LoggingHandlers.java I am attaching the diff for 3.1.2 in case management believe this needs to be in 3.1.2 too.
        Hide
        Anissa Lam added a comment -

        Previous comment from Naman says:
        "When you change log levels through admin console it's going to update logging.proeprties file on DAS and then trying to replicate on the instance machine. But sometimes we are stopping instance before replication is successful and which corrupts the logging.properties file on remote machine. "

        Console code is using the correct API but of course should be more efficient, should call set-log-levels once instead of in a loop. I fixed this in the trunk now. I feel that the console change is just masking the root problem.
        Besides triggered by console, will there be other situation that the replication failed affecting logging.properties ?

        I am changing this back to logging for Naman to put in the proper fix, maybe by catching the NPE.
        Caused by: java.lang.NullPointerException
        at com.sun.enterprise.server.logging.GFFileHandler.postConstruct(GFFileHandler.java:162)

        Show
        Anissa Lam added a comment - Previous comment from Naman says: "When you change log levels through admin console it's going to update logging.proeprties file on DAS and then trying to replicate on the instance machine. But sometimes we are stopping instance before replication is successful and which corrupts the logging.properties file on remote machine. " Console code is using the correct API but of course should be more efficient, should call set-log-levels once instead of in a loop. I fixed this in the trunk now. I feel that the console change is just masking the root problem. Besides triggered by console, will there be other situation that the replication failed affecting logging.properties ? I am changing this back to logging for Naman to put in the proper fix, maybe by catching the NPE. Caused by: java.lang.NullPointerException at com.sun.enterprise.server.logging.GFFileHandler.postConstruct(GFFileHandler.java:162)
        Hide
        Anissa Lam added a comment -

        Attached console-common.jar which has the changes in console for 3.1.2.

        To test this:
        install OGS promoted build 21.
        cd <glassfish-install>/glassfish/modules
        mv console-common.jar console-common.jar.ORIG
        cp <Download>/console-common.jar .

        rm -rf <glassfish-install>/glassfish/domains/domain1/osgi-cache

        restart domain.

        Show
        Anissa Lam added a comment - Attached console-common.jar which has the changes in console for 3.1.2. To test this: install OGS promoted build 21. cd <glassfish-install>/glassfish/modules mv console-common.jar console-common.jar.ORIG cp <Download>/console-common.jar . rm -rf <glassfish-install>/glassfish/domains/domain1/osgi-cache restart domain.
        Hide
        lidiam added a comment -

        Tested patch on existing build. It works like a charm. Tried the scenario 10 times and did not see the issue. Also, now log levels update takes less than a second (before it was taking around 12 seconds). I didn't wait at all between logging levels changes and instance restarts and it all worked.

        Show
        lidiam added a comment - Tested patch on existing build. It works like a charm. Tried the scenario 10 times and did not see the issue. Also, now log levels update takes less than a second (before it was taking around 12 seconds). I didn't wait at all between logging levels changes and instance restarts and it all worked.
        Hide
        naman_mehta added a comment -

        This issue is coming due to replication error or file is not properly updated on remote machine and instance is not able to coming up as some properties are missing. To avoid this we can make following changes,

        Index: src/main/java/com/sun/enterprise/server/logging/GFFileHandler.java
        ===================================================================
        — src/main/java/com/sun/enterprise/server/logging/GFFileHandler.java (revision 52453)
        +++ src/main/java/com/sun/enterprise/server/logging/GFFileHandler.java (working copy)
        @@ -154,13 +154,25 @@
        String recordFieldSeparator;
        String recordDateFormat;

        + String logFileProperty = "";
        +
        public void postConstruct() {

        LogManager manager = LogManager.getLogManager();
        String cname = getClass().getName();

        • String filename = TranslatedConfigView.getTranslatedValue(manager.getProperty(cname + ".file")).toString();
          + if (manager != null) { + logFileProperty = manager.getProperty(cname + ".file"); + }

        + if (logFileProperty == null || logFileProperty.trim().equals(""))

        { + logFileProperty = env.getInstanceRoot().getAbsolutePath() + File.separator + LOGS_DIR + File.separator + + logFileName; + }

        +
        + String filename = TranslatedConfigView.getTranslatedValue(logFileProperty).toString();
        +
        +
        File serverLog = new File(filename);
        absoluteServerLogName = filename;
        if (!serverLog.isAbsolute()) {

        Above changes will check for the required property is present or not if not it would create log files under installation directory. And now server will come up and later the new logging.properties file is replicated to the remote machine and which could solve the problem.

        This fix is to avoid to avoid catastrophic failure in the absence of a user defined configuration property like com.sun.enterprise.server.logging.GFFileHandler.file. It's just to avoid instance startup error.

        Show
        naman_mehta added a comment - This issue is coming due to replication error or file is not properly updated on remote machine and instance is not able to coming up as some properties are missing. To avoid this we can make following changes, Index: src/main/java/com/sun/enterprise/server/logging/GFFileHandler.java =================================================================== — src/main/java/com/sun/enterprise/server/logging/GFFileHandler.java (revision 52453) +++ src/main/java/com/sun/enterprise/server/logging/GFFileHandler.java (working copy) @@ -154,13 +154,25 @@ String recordFieldSeparator; String recordDateFormat; + String logFileProperty = ""; + public void postConstruct() { LogManager manager = LogManager.getLogManager(); String cname = getClass().getName(); String filename = TranslatedConfigView.getTranslatedValue(manager.getProperty(cname + ".file")).toString(); + if (manager != null) { + logFileProperty = manager.getProperty(cname + ".file"); + } + if (logFileProperty == null || logFileProperty.trim().equals("")) { + logFileProperty = env.getInstanceRoot().getAbsolutePath() + File.separator + LOGS_DIR + File.separator + + logFileName; + } + + String filename = TranslatedConfigView.getTranslatedValue(logFileProperty).toString(); + + File serverLog = new File(filename); absoluteServerLogName = filename; if (!serverLog.isAbsolute()) { Above changes will check for the required property is present or not if not it would create log files under installation directory. And now server will come up and later the new logging.properties file is replicated to the remote machine and which could solve the problem. This fix is to avoid to avoid catastrophic failure in the absence of a user defined configuration property like com.sun.enterprise.server.logging.GFFileHandler.file. It's just to avoid instance startup error.
        Hide
        lidiam added a comment -

        It seems to me that with the above solution we will totally hide the issue, i.e. we will never know if logging.properties file got truncated/corrupted. I think we should at least print a WARNING level message to server.log indicating that there is a problem.

        Show
        lidiam added a comment - It seems to me that with the above solution we will totally hide the issue, i.e. we will never know if logging.properties file got truncated/corrupted. I think we should at least print a WARNING level message to server.log indicating that there is a problem.
        Hide
        Anissa Lam added a comment -

        The changes in GUI to call set-log-levels once for all loglevels has been checked in to 3.1.2 branch with Joe's request.
        This should be in 3.1.2 RC4 build.

        Log Message:
        ------------
        Improve performance of GUI when changing log levels and to avoid a bug in logging, GLASSFISH-18336.
        Revisions:
        ----------
        52545
        Modified Paths:
        ---------------
        branches/3.1.2/admingui/common/src/main/java/org/glassfish/admingui/common/handlers/LoggingHandlers.java

        Show
        Anissa Lam added a comment - The changes in GUI to call set-log-levels once for all loglevels has been checked in to 3.1.2 branch with Joe's request. This should be in 3.1.2 RC4 build. Log Message: ------------ Improve performance of GUI when changing log levels and to avoid a bug in logging, GLASSFISH-18336 . Revisions: ---------- 52545 Modified Paths: --------------- branches/3.1.2/admingui/common/src/main/java/org/glassfish/admingui/common/handlers/LoggingHandlers.java
        Hide
        Rebecca Parks added a comment -

        Per Sudipa, removed from Release Notes due to the fix.

        Show
        Rebecca Parks added a comment - Per Sudipa, removed from Release Notes due to the fix.
        Hide
        Joe Di Pol added a comment -

        A work-around was implemented in the console, so this bug is not hitting users anymore. But there is still an NPE in the backend that should be fixed. I'm lowering the priority to P4 since there is limited customer impact.

        Show
        Joe Di Pol added a comment - A work-around was implemented in the console, so this bug is not hitting users anymore. But there is still an NPE in the backend that should be fixed. I'm lowering the priority to P4 since there is limited customer impact.
        Hide
        naman_mehta added a comment -

        Added backend changes for 4.0.

        Show
        naman_mehta added a comment - Added backend changes for 4.0.

          People

          • Assignee:
            naman_mehta
            Reporter:
            lidiam
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated: