glassfish
  1. glassfish
  2. GLASSFISH-17570

information from get-health is not displayed

    Details

    • Type: Improvement Improvement
    • Status: Reopened
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: 3.1.1
    • Fix Version/s: future release
    • Component/s: admin_gui
    • Labels:
      None
    • Environment:

      cli-parity

      Description

      get-health provides more information for each instance in the cluster.
      In the cluster instance general info page, should provide the additional info about this instance.

        Issue Links

          Activity

          Hide
          Anissa Lam added a comment -

          Fix checked into both trunk and 3.1.2 branch.
          The return from get-health is displayed in the cluster instance General info page. However, there maybe i18n issue. Will file an issue on that. But the support is in.

          Log Message:
          ------------
          GLASSFISH-17570. Display get-health info in the cluster instance page.
          Revisions:
          ----------
          50993
          Modified Paths:
          ---------------
          branches/3.1.2/admingui/cluster/src/main/resources/shared/handlers.inc
          branches/3.1.2/admingui/cluster/src/main/resources/cluster/clusterInstanceEdit.jsf

          =============================

          Revisions:
          ----------
          50994
          Modified Paths:
          ---------------
          trunk/main/appserver/admingui/cluster/src/main/resources/cluster/clusterInstanceEdit.jsf
          trunk/main/appserver/admingui/cluster/src/main/resources/shared/handlers.inc

          Show
          Anissa Lam added a comment - Fix checked into both trunk and 3.1.2 branch. The return from get-health is displayed in the cluster instance General info page. However, there maybe i18n issue. Will file an issue on that. But the support is in. Log Message: ------------ GLASSFISH-17570 . Display get-health info in the cluster instance page. Revisions: ---------- 50993 Modified Paths: --------------- branches/3.1.2/admingui/cluster/src/main/resources/shared/handlers.inc branches/3.1.2/admingui/cluster/src/main/resources/cluster/clusterInstanceEdit.jsf ============================= Revisions: ---------- 50994 Modified Paths: --------------- trunk/main/appserver/admingui/cluster/src/main/resources/cluster/clusterInstanceEdit.jsf trunk/main/appserver/admingui/cluster/src/main/resources/shared/handlers.inc
          Hide
          Anissa Lam added a comment -

          Reopen the issue, since how UI should change to support this is under discussion again.

          Show
          Anissa Lam added a comment - Reopen the issue, since how UI should change to support this is under discussion again.
          Hide
          Anissa Lam added a comment -

          With more understanding on what get-health returns and discussion with Nazrul, its decided that we will not support get-health unless the console can also provide support for validate-multicast. Thats more informative to the user.
          Lowering the priority and target for future release till backend consider to make validate-multicast a remote command.

          Show
          Anissa Lam added a comment - With more understanding on what get-health returns and discussion with Nazrul, its decided that we will not support get-health unless the console can also provide support for validate-multicast. Thats more informative to the user. Lowering the priority and target for future release till backend consider to make validate-multicast a remote command.
          Hide
          Bobby Bissett added a comment -

          I'm not sure the use case of validate-multicast is well understood here. It's a low-level network debugging tool that's meant to be run iteratively while trying to get multicast working between nodes. Even if a remote version of the command ever exists, just running it one time in the admin console won't give much more information than what you get from get-health. And you won't be able to fix the problems through the admin console (e.g., misconfigured router or machines on different subnets). We even state that the app servers should be shut down when trying to fix this problem.

          If you can show the cluster health in admin console, then I think you should. Don't withhold some useful info just because it's not all the info. IMO, if the instances are running (list-instances shows them up), but they're not seeing each other (get-health shows them down), then the cluster is broken. We tell users to manually run get-health, but that doesn't mean they do, and a single instance that's running but is isolated from the group is a bad problem waiting to happen – no one may notice till it fails and sessions are not replicated anywhere.

          All you'd have to do is add a sentence on the page that if the output from the two commands differs, there is a problem in the cluster and they need to debug it.

          Show
          Bobby Bissett added a comment - I'm not sure the use case of validate-multicast is well understood here. It's a low-level network debugging tool that's meant to be run iteratively while trying to get multicast working between nodes. Even if a remote version of the command ever exists, just running it one time in the admin console won't give much more information than what you get from get-health. And you won't be able to fix the problems through the admin console (e.g., misconfigured router or machines on different subnets). We even state that the app servers should be shut down when trying to fix this problem. If you can show the cluster health in admin console, then I think you should. Don't withhold some useful info just because it's not all the info. IMO, if the instances are running (list-instances shows them up), but they're not seeing each other (get-health shows them down), then the cluster is broken . We tell users to manually run get-health, but that doesn't mean they do, and a single instance that's running but is isolated from the group is a bad problem waiting to happen – no one may notice till it fails and sessions are not replicated anywhere. All you'd have to do is add a sentence on the page that if the output from the two commands differs, there is a problem in the cluster and they need to debug it.
          Hide
          Tom Mueller added a comment -

          +1 to Bobby's comment.

          However, the GUI implementation needs to take into account whether GMS is even enabled for a cluster. (Maybe it already does). If GMS is not enabled for a cluster,then the get-health information should not be displayed.

          Show
          Tom Mueller added a comment - +1 to Bobby's comment. However, the GUI implementation needs to take into account whether GMS is even enabled for a cluster. (Maybe it already does). If GMS is not enabled for a cluster,then the get-health information should not be displayed.

            People

            • Assignee:
              Anissa Lam
              Reporter:
              Anissa Lam
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated: