[jboss-jira] [JBoss JIRA] (AS7-4388) Provide clustering management use cases

[ https://issues.jboss.org/browse/AS7-4388?page=com.atlassian.jira.plugin.s... ] Richard Achmatowicz commented on AS7-4388: ------------------------------------------ 1. Given the requirements mentioned above, I propose the following high-level additions to the clustering management subsystems (JGroups and Infinispan for now): - addition of runtime metrics for runtime services in JGroups (channels) and Infinispan (cache-managers, caches) - addition of cluster-related information and operations (cluster membership, shared transport, other cluster-specific operations) 1.1 For JGroups: /subsystem=jgroups/stack=* /subsystem=jgroups/channel=* /subsystem=jgroups/cluster=* The stack resource exists already and represents a persistent stack configuration. It exposes transport and protocol configuration attributes. The channel resource will be new and each child resource instance represents a run-time Channel instance created from a given stack. It will expose transport and protocol read-only,runtime metrics as well as read-only versions of transport and protocol configuration attributes from the associated stack (a la JMX in previous versions of AS). The cluster resource will represent a cluster (a set of JGroups channels, possibly on different nodes). Attributes of a cluster may expose the group view or other cluster-wide attributes; operations may perform cluster-wide operations. Cluster children represent cluster members and expose the channel=* resources on that node. /subsystem=jgroups/channel=X /subsystem=jgroups/cluster=X/member-address=192.168.0.100 /subsystem=jgroups/cluster=X/member-address=192.168.0.101 The way in which cluster members are identified may require more than IP address (e.g. two JGroups channels on the same node). Cluster differs from channel in that channel exposes only the JGroups resources on a single node, whereas cluster exposes resources across the cluster. The user may thus view cluster-wide information from a single CLI window. A JGroups RPC mechanism and appropriate handler can be used to obtain management info from other nodes, in domain or standalone modes. Because JGroups starts services on-demand, channels and clusters need to be implemented as custom resources which are presented iff the runtime services which back them up have been started. 1.2 For Infinispan /subsystem=infinispan/cache-manager=* /subsystem=infinispan/cache-manager=*/local-cache=* /subsystem=infinispan/cache-manager=*/invalidation-cache=* /subsystem=infinispan/cache-manager=*/replicated-cache=* /subsystem=infinispan/cache-manager=*/distributed-cache=* /subsystem=infinispan/cluster=* The cache-manager and x-cache resources already exist and represent persistent cache manager and cache configurations. Unlike channels, which are represent runtime instances and whose configuration is tied to a stack definition, cache-managers and caches can represent both a configuration as well as a run-time instance. So existing cache-manager and cache resources may be extended with read-only, runtime metrics without defining any new resources. As in the case of JGroups, an Infinispan cluster can represent cluster-wide attributes associated with the cluster (e.g. transport) and cluster wide operations. Cluster children represent cluster members and expose the cache-manager=* resources (and cache children) on that node. /subsystem=infinispan/cluster=X /subsystem=infinispan/cluster=X/member-address=192.168.0.100 /subsystem=infinispan/cluster=X/member-address=192.168.0.101 Why have a cluster=* resource defined in two subsystems? An Infinispan cluster presents a view of a cluster from the Infinispan level(transactions, evictions, etc); a JGroups cluster from the JGroups level(RPCs, bytes sent, etc). 1.3 Comments Introduction of the cluster resource is experimental only and presented now for discussion. I think its natural for a user to want to see what is happening in a cluster, as opposed to only on a single node. Feedback appreciated. Introduction of the channel resources and extension of the cache-manager and cache resources is planned and needs to be completed asap. 2. Implementation Issues (Brian, Kabir, Tomas) 2.1 Paul and I discussed the placement of channel=* and felt that locating them on the same level as stack=* was better than as a child, as when looking at a channel, we don't really care which stack is being used. This is instead of locating channel as children of stack. Any objections? 2.2 In the case of channel, I would like to expose all of the stack attributes (transport/protocols) in read-only fashion, and append the runtime metrics to that. Why? So that (i) for example, all protocol=MPING information, both configuration and runtime metrics, can been seen from the same resource, as in the old JMX view and (ii) the user knows that in order to modify the stack, he has to modify it from the stack=* address and this will affect all channels derived from that stack. And I wanted to do this without having to define "run-time only" versions of the existing transport and protocol resources under stack. But this requires being able to take a resource X whose attributes are exposed as storage=configuration, access=read-write in one part of the tree and expose it in another part of the tree as storage=configuration, access=read-only. Kabir and I were discussing possible ways to do this, one of which was to use aliasing with some customization. Ideas? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira