Issue Details (XML | Word | Printable)

Key: GLASSFISH-17570
Type: Improvement Improvement
Status: Reopened Reopened
Priority: Minor Minor
Assignee: Anissa Lam
Reporter: Anissa Lam
Votes: 0
Watchers: 2

If you were logged in you would be able to see more operations.

information from get-health is not displayed

Created: 02/Nov/11 06:56 AM   Updated: 30/Nov/11 07:49 PM
Component/s: admin_gui
Affects Version/s: 3.1.1
Fix Version/s: future release

Time Tracking:
Issue & Sub-Tasks
Issue Only
Not Specified



Issue Links:

Participants: Anissa Lam, Bobby Bissett and Tom Mueller

  • Sub-Tasks:
  • All
  • Open

 Description  « Hide

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.

Anissa Lam added a comment - 20/Nov/11 10:23 PM

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.
Modified Paths:


Modified Paths:

Anissa Lam added a comment - 23/Nov/11 06:50 PM

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

Anissa Lam added a comment - 30/Nov/11 04:25 AM

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.

Bobby Bissett added a comment - 30/Nov/11 07:11 PM

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.

Tom Mueller added a comment - 30/Nov/11 07:49 PM

+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.