Feature # |
Priority |
Description |
Comments |
Milestone |
GMS-1.0.01 |
P4 |
Administrators shall be able to configure a GMS group discovery mechanism for a site. Probably being replaced by environment-based automated generation of VIRTUAL_MULTICAST_URI_LIST. |
Mechanism is used to enable a GMS cluster when UDP multicast is unavailable between clustered instances. Provide CLI to install a group discovery service as an OS service at a Well Known Address. Provide CLI to configure VM template to reference a site-wide group discovery mechanism. Provide CLI to configure S3-based group discovery. (Derived from GlassFish 3.2 PRD Feature ID CLUST-1) (See GF-3636 for issue that GMS requires UDP multicast.) https://github.com/javaee/glassfish/issues/16413 |
4 |
GMS-1.0.02 |
P1 |
Administrator shall be able to configure a cluster to not require UDP multicast. |
Provide new Cluster properties to asadmin create-cluster subcommand to use non-multicast rather than default of UDP multicast. (Derived from GlassFish 3.2 PRD Feauture ID CLUST-1) https://github.com/javaee/glassfish/issues/16414 |
3 |
GMS-1.0.03 |
P2 |
Administrator shall be able to configure GMS TCP point to point messages to use SSL. |
Enable administrator to secure application session data when it is being replicated due to availability of session data being enabled. Reuse existing ssl element defined in domain.xml and use it to configure SLLConfig object to use with Grizzly 2.0 filter. See GF-14664 |
5 |
GMS-1.0.04 |
P2 |
Administrators shall be able to configure clustered instances to potentially be separated by a firewall. |
Support for hybrid cloud (part private and part public cloud). Default heartbeat failure detection configuration will require adjustment to account for potentially slower network throughput across the firewall. https://github.com/javaee/glassfish/issues/16415 |
6 |
GMS-1.0.05 |
|
(previously deleted) |
|
|
GMS-1.0.06 |
P2 |
GMS Monitoring Stats Provider |
Monitor GMS messaging by target component. Monitor heartbeat overhead. Monitor GMS notifications and how often a rebroadcast was necessary due to a dropped UDP multicast message. See GF-12194 . Task will be ongoing. Some stats will be ready earlier -- milestone date is for all stats. |
5 |
GMS-1.0.07 |
P3 |
Administrator shall be able to create up to 10 instances in a cluster |
No known issues supporting this with or without multicast. GlassFish 3.1 GMS QE tests for 9 instances due to limited machine resources. (Derived from GlassFish 3.2 PRD Feauture ID CLUST-3 Scalable Clusters) |
|
GMS-1.0.08 |
P3 |
Administrator shall be able to create 20 clusters in a domain. |
This is a non-issue when DAS is not running and none of the clusters are experiencing high application load. However, if DAS is running and is master for all 20 clusters, need to investigate this scenario for both UDP multicast and non-multicast configurations. Redesign of centralized master processing may be needed to support this case properly. (Derived from GlassFish 3.2 PRD Feauture ID CLUST-3 Scalable Clusters) GlassFish 3.1 GMS QE has scenarios for 2 clusters. |
|
GMS-1.0.09 |
P2 |
Administrator shall be able to configure heartbeats to be sent over UDP unicast transport when multicast is disabled. |
https://github.com/javaee/glassfish/issues/16416 |
TBD |
GMS-1.0.10 |
P3 |
asadmin get-health needs to work in self configuring(ad hoc clusters) cluster env |
Derived from Cluster Management Requirement 1.0.7. In GlassFish 3.1, this command only runs against the DAS and there is no DAS in self configuring cluster env. Other commands that run against the DAS (list-instance, start-cluster) are non-requirements. So need to evaluate if this command should be implemented for self-configuring cluster. Health info could be stored in GMS master. Command needs to be able to locate the master via cluster name. (investigate means to associate clustername with configuration info such as GMS_DISCOVERY_URI_LIST) (Derived from GF 3.2 PRD Feature ID CLUST-2 Ad Hoc Clusters) https://github.com/javaee/glassfish/issues/16417 |
|
GMS-1.0,11 |
P1 |
New Heartbeat Failure Detection implementation optimized for non-multicast and no DAS |
Self-configuring cluster case. (Note: This item's priority should track priority of self-configuring cluster priority.) https://github.com/javaee/glassfish/issues/16418 |
5 |
GMS-1.0.12 |
P3 |
Support for OS configured with IPv6 only |
When multicast is not disabled, an IPv4 format multicast address is being generated. This does not work in a IPv6 env. See workaround described in GF-16103 . (specify an explicit IPv6 multicastaddress using --mulicastaddress parameter to create-cluster) Typically, one runs in a dual stack environment and ipv4 mapped addresses over ipv6 sockets is the java default for working in these env. |
|
GMS-1.0.13 |
P2 |
Virtual multicast optimization to send messages concurrently. |
Only reason to wait for completion of send is to be notified of failed delivery. With Grizzly 2.0 using async send, should be easy to have a nowait mode for delivery. Point 2 point messges could be sent synchronous and unicast sends that are part of a broadcast could be sent without waiting for send to complete. https://github.com/javaee/glassfish/issues/16419 |
5 |
GMS-1.0.14 |
P1 |
New GMS configuration info on cluster and group-management-service element in domain.xml |
Cluster properties DISCOVERY_REGISTRATION_URI_LIST, VIRTUAL_MULTICAST_URI_LIST New heartbeat failure detection implementation may need alternative configuration parameters. (given different algorithm) (unknown at this point) SSL configuration for GMS TCP. GMS Member authentication. (Impacts GMSAdapterImpl config processing, asadmin create-cluster subcommand parameters) If using S3 for group discovery, users will need to be able to specify AWS credentials as well. This should probably live in a separate file (e.g. a properties file in config directory). https://github.com/javaee/glassfish/issues/16420 Can be done before MS4, but without GMS-1.0.01 there is nothing to test. |
3 |
GMS-1.0.15 |
P3 |
GMS Member authentication when member is joining. |
See GF-14663. This would be an optional capability that would need to be configured by GlassFish administrator. |
|
GMS-1.0.16 |
P1 |
Factor Shoal GMS grizzly transport dependent classes into shoal-gms-grizzly-1_9.jar and shoal-gms-grizzly-2_0.jar. |
Completes transition from grizzly 1.9 to grizzly 2.0 for shoal gms impl jar. When completed shoal-gms-grizzly-2_0.jar would be integrated into GlassFish 3.2 branch. Currently shoal gms grizzly transport support for both 1.9 and 2.0 are in shoal-gms-impl.jar integrated with glassfish 3.2 workspace. https://github.com/javaee/glassfish/issues/16421 |
3 |
GMS-1.0.17 |
P3 |
Support secure communications with discovery service. |
With our own REST implementation of the discovery service, it would be nice to have it be secured so that only GMS members can talk to it and the information is confidential. But this isn't necessary for having GMS work, and the service can live behind the firewall. The only information stored there is the location of the group master. With help from the Jersey team, this may be easy to implement. But it's lower priority than getting everything working. |
|