updatecenter2
  1. updatecenter2
  2. UPDATECENTER2-613

UC bootstrap hangs during notifier registration

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Critical Critical
    • Resolution: Won't Fix
    • Affects Version/s: 2.0-MS14
    • Fix Version/s: not determined
    • Component/s: bootstrap
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      613

      Description

      This issue corresponds to GF issue# 5830:

      https://glassfish.dev.java.net/issues/show_bug.cgi?id=5830

        Activity

        Hide
        Anissa Lam added a comment -

        Actually i am seeing the same problem in admin gui. GUi uses the java client
        jar, and every once in a while, when i call image.installPackages(), it never
        returns. Browser just keeps waiting.

        Show
        Anissa Lam added a comment - Actually i am seeing the same problem in admin gui. GUi uses the java client jar, and every once in a while, when i call image.installPackages(), it never returns. Browser just keeps waiting.
        Hide
        Tom Mueller added a comment -

        We need to get a reproducible test case for this.

        If this hang problem is related to registration of the notifier, it is highly
        unlikely that Annisa is seeing the same problem in the admin GUI because the
        admin GUI doesn't use the pkg-bootstrap.jar file where the notifier registration
        is done. Also, notifier registration is not done by the Image.installPackages()
        call.

        Show
        Tom Mueller added a comment - We need to get a reproducible test case for this. If this hang problem is related to registration of the notifier, it is highly unlikely that Annisa is seeing the same problem in the admin GUI because the admin GUI doesn't use the pkg-bootstrap.jar file where the notifier registration is done. Also, notifier registration is not done by the Image.installPackages() call.
        Hide
        Chris Kasso added a comment -

        In 5830 it says:

        • GF v3 installer hangs during UC configuration. Notifier apparently gets
          registered since firewall prompts to allow python process to access the network.
        • Notifier popup Window informs about available updates. Installer still hangs.
        • Only after clicking on popup, starting updatetool GUI and exiting control is
          returned back to installer and installation continues.

        Based in this it implies the bootstrapper was able to successfully register
        the notifier and start the notifier. The exec statement for starting the
        notifier in the bootstrapper does not do a proc.waitFor() after the exec()
        so the bootstrapper is not waiting for the exec of the notifier to return.

        The bootstrapper does log messages at the INFO level so maybe checking the log
        info could be useful in understanding where the code is getting stuck.

        Show
        Chris Kasso added a comment - In 5830 it says: GF v3 installer hangs during UC configuration. Notifier apparently gets registered since firewall prompts to allow python process to access the network. Notifier popup Window informs about available updates. Installer still hangs. Only after clicking on popup, starting updatetool GUI and exiting control is returned back to installer and installation continues. Based in this it implies the bootstrapper was able to successfully register the notifier and start the notifier. The exec statement for starting the notifier in the bootstrapper does not do a proc.waitFor() after the exec() so the bootstrapper is not waiting for the exec of the notifier to return. The bootstrapper does log messages at the INFO level so maybe checking the log info could be useful in understanding where the code is getting stuck.
        Hide
        Chris Kasso added a comment -

        Here's what I believe is going on:

        The OI configurator in the GF installer does the following:

        javaExecuteCommand.setCollectOutput(true);
        javaExecuteCommand.execute();
        productError = javaExecuteCommand.getErrors();

        This causes OI to read the error output from the process that it
        spawns.

        The process that it spawns (the UC bootstrapper) spawns a second,
        long running process - the notifier. The UC bootstrapper does not
        wait for the notifier to exit, nor does it attempt to capture the
        output stream from that process. The bootstrapper just launches
        the notifier then finishes its work and exits. It doesn't care
        whether the notifier was sucessfully started or not.

        On Windows it appears that when the bootstrapper process exits the
        OI process inherits the notifier's output stream. Instead of
        only reading the output from the bootstrapper OI configurator is also
        is waiting on any output from the notifier (python).

        This does not occur on Solaris. It seems to be Windows specific.

        I suspect that on Windows if the OI configurator did not attempt to
        collect the error output from the UC bootstrapper this problem would
        go away. It would also go away if the bootstrapper did not attempt
        to start the notifier.

        This explains why some folks do not see this problem. If the notifier
        is already running when they install GF or they choose not to enable
        UC notifications the notifier will not be started or it will exit
        immediately when it sees that one is already running - thus no issue.
        It is only when the bootstrapper starts the notifier and an instance
        is not already running will this problem occur.

        One option might be to not use the ExecuteCommand in the OI configurator
        but rather use Runtime.exec directly and manage the input/out stream
        directly. Use InputStream.available() to test whether there is any
        error output to read from the bootstrapper.

        Show
        Chris Kasso added a comment - Here's what I believe is going on: The OI configurator in the GF installer does the following: javaExecuteCommand.setCollectOutput(true); javaExecuteCommand.execute(); productError = javaExecuteCommand.getErrors(); This causes OI to read the error output from the process that it spawns. The process that it spawns (the UC bootstrapper) spawns a second, long running process - the notifier. The UC bootstrapper does not wait for the notifier to exit, nor does it attempt to capture the output stream from that process. The bootstrapper just launches the notifier then finishes its work and exits. It doesn't care whether the notifier was sucessfully started or not. On Windows it appears that when the bootstrapper process exits the OI process inherits the notifier's output stream. Instead of only reading the output from the bootstrapper OI configurator is also is waiting on any output from the notifier (python). This does not occur on Solaris. It seems to be Windows specific. I suspect that on Windows if the OI configurator did not attempt to collect the error output from the UC bootstrapper this problem would go away. It would also go away if the bootstrapper did not attempt to start the notifier. This explains why some folks do not see this problem. If the notifier is already running when they install GF or they choose not to enable UC notifications the notifier will not be started or it will exit immediately when it sees that one is already running - thus no issue. It is only when the bootstrapper starts the notifier and an instance is not already running will this problem occur. One option might be to not use the ExecuteCommand in the OI configurator but rather use Runtime.exec directly and manage the input/out stream directly. Use InputStream.available() to test whether there is any error output to read from the bootstrapper.
        Hide
        Tom Mueller added a comment -

        Good sleuthing, Chris.

        Is there a way in the notifier startup process then when the notifier is
        actually started, the standard out and error streams are closed?

        Show
        Tom Mueller added a comment - Good sleuthing, Chris. Is there a way in the notifier startup process then when the notifier is actually started, the standard out and error streams are closed?
        Hide
        Chris Kasso added a comment -

        In my pure java test case that simulates the long running process
        I tried:

        System.out.close();
        System.err.close();
        System.in.close();

        as well as:

        System.setOut(null);
        System.setErr(null);
        System.setIn(null);

        but it made no difference.

        I also tried closing the subprocess streams for the parent's
        process context:

        InputStream stdin = process.getInputStream();
        stdin.close();

        But no change in behavior.

        Show
        Chris Kasso added a comment - In my pure java test case that simulates the long running process I tried: System.out.close(); System.err.close(); System.in.close(); as well as: System.setOut(null); System.setErr(null); System.setIn(null); but it made no difference. I also tried closing the subprocess streams for the parent's process context: InputStream stdin = process.getInputStream(); stdin.close(); But no change in behavior.
        Hide
        Chris Kasso added a comment -

        For background on the issue see comments from kasso Fri Sep 5 18:24:25 above.

        To close out this issue I will update the Update Center 2.0
        Toolkit Initialization Interface spec:

        http://wiki.updatecenter.java.net/Wiki.jsp?page=UC20FSD.InitInterface

        to highlight this issue for Windows based consumers of the initialization
        interface.

        Specifically it will recommend that Java based installers should not
        exec the pkg-bootstrap.jar file. The recommendation will be to
        use the Java based API and pass a logger in order to capture output
        during the UC initialization.

        Consumers of the initialization interface who can not use the API directly
        but must exec the jar file must be careful on the Windows platform to
        not block on reads if they have requested the notifier to be started
        as part of the initialization process.

        There are no UC code changes related to this issue. The issue is being
        closed as "WONTFIX".

        Show
        Chris Kasso added a comment - For background on the issue see comments from kasso Fri Sep 5 18:24:25 above. To close out this issue I will update the Update Center 2.0 Toolkit Initialization Interface spec: http://wiki.updatecenter.java.net/Wiki.jsp?page=UC20FSD.InitInterface to highlight this issue for Windows based consumers of the initialization interface. Specifically it will recommend that Java based installers should not exec the pkg-bootstrap.jar file. The recommendation will be to use the Java based API and pass a logger in order to capture output during the UC initialization. Consumers of the initialization interface who can not use the API directly but must exec the jar file must be careful on the Windows platform to not block on reads if they have requested the notifier to be started as part of the initialization process. There are no UC code changes related to this issue. The issue is being closed as "WONTFIX".

          People

          • Assignee:
            Chris Kasso
            Reporter:
            Snjezana Sevo-Zenzerovic
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: