Status: Resolved (View Workflow)
Affects Version/s: None
Fix Version/s: 8.0.0.Final
Component/s: Web (Undertow)
Steps to Reproduce:Hide
i)Setup a modcluster instance with two AS7 nodes(running on two different machines).
ii)Use read-proxy-info to view list of Nodes/cluster members and their identifiers.
iii)Attempt to execute disable*/enable*/stop* operations and they will only affect one of the nodes.
iv)Browsing the modcluster subsystem this is no way to view the jvmRoute identifier.
v) Without it is is unclear how to determine what from the proxyInformation is relevant to a specific AS7 instance.Showi)Setup a modcluster instance with two AS7 nodes(running on two different machines). ii)Use read-proxy-info to view list of Nodes/cluster members and their identifiers. iii)Attempt to execute disable*/enable*/stop* operations and they will only affect one of the nodes. iv)Browsing the modcluster subsystem this is no way to view the jvmRoute identifier. v) Without it is is unclear how to determine what from the proxyInformation is relevant to a specific AS7 instance.
Similar Issues:Show 10 results
WFLY-179 CLONE - Adding modcluster via the CLI fails. WFLY-367 Expose "upload-deployment-url" operation via the CLI high-level "deploy" command WFLY-357 Expose module loading information via the management API WFLY-1339 Expose mod_cluster operations when running in domain mode WFLY-1316 Missing operation description for the "composite" operation prevents its use in CLI WFLY-83 Management operations for accessing transaction logs should be exposed in the web console WFLY-996 No way to query valid property values for objects of type PROPERTY via cli WFLY-125 Attribute passivate-events-on-replicate of cluster-passivation-store can't be change via drm or cli WFLY-2376 DataSource properties are not persisting via CLI WFLY-3166 can't enable datasource both via console or CLI with cluster mode(can't persist to domain.xml)
The modcluster subsystem needs to expose the 'jvmRoute' identifier via cli for the modcluster subsystem at the configuration level(at subsystem=modcluster/mod-cluster-config=configuration level). Without this information it is ambiguous how and which contexts will be affected when you execute the following operations:
disable, disable-context, enable, enable-context, stop, stop-context.
The other configuration attributes/operations target cluster-wide configuration, but the previous list of operations can only be executed at the cluster member/node level. In other words, a modcluster group could have 30 members/nodes but the above CLI operations will only affect the virtual-hosts and contexts for one of those nodes as uniquely identified by the jvmRoute. There is currently no consistent way to determine what a valid cluster identifier should be.
The jvmRoute can be explicitly set via the 'jboss.mod_cluster.jvmRoute' property or is automatically generated. Either way the correct jvmRoute or modcluster node identifier information needs to be correctly exposed as read-only information for the modcluster subsystem.
This post (https://community.jboss.org/message/632900), mentions an 'instance-id' on the web subsytem but it is also 'undefined' even for systems where the jvmRoute has been explicitly set or autogenerated.
As the identifier is used by modcluster the identifier should be exposed consistently.
Additionally there is no way to read whether a specific context is enabled/disabled. That issue probably needs it's another JIRA though.