[ https://issues.jboss.org/browse/AS7-4388?page=com.atlassian.jira.plugin.s... ] Dennis Reed commented on AS7-4388: ---------------------------------- Must have --------- Modify JGroups configurations - switch "default-stack" - add/delete alternate stacks - add/delete protocols in a stack - modify protocol parameters Modify Infinispan configurations - modify some cache parameters (repl/dist, SYNC/ASYNC, batching, timeouts, eviction/expiration settings on some caches) Monitor current cluster membership of all JGroups channels Nice to have ------------ Detailed JGroups details (view history, packet retransmissions, etc) Detailed Infinispan details (number of nodes, etc) Automated testing/configuration in a domain (test multicast between nodes, set TCPPING.initial_hosts based on domain member list, etc) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-4388?page=com.atlassian.jira.plugin.s... ] Mircea Markus commented on AS7-4388: ------------------------------------ This might already be covered by existing functionality, but this is what I find useful: - start a new node with a given JVM (memory mainly) configuration - stop a node or a set of them(batch stop) at once - process info for each node: memory usage, gc activity - some alerts would be handy in the case of: nodes too loaded, nodes don't have enough load - schedule nodes start/stop at certain fixed times -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ 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

[ https://issues.jboss.org/browse/AS7-4388?page=com.atlassian.jira.plugin.s... ] Dennis Reed commented on AS7-4388: ---------------------------------- That should already be available in domain mode, or using any other tool (JON) that looks at multiple nodes. And it's not specific to the JGroups/Infinispan subsystems. The same argument of wanting to see data across nodes would apply to most subsystems. I don't think that functionality should be duplicated in a different way. Don't duplicate the information already available under stack=! What would be useful under the runtime part would be exposing the actual JGroups protocol info (the current data, which could be different from the configuration if things were changed at runtime). It would also be nice to see the runtime part not be limited to channels created by the AS JGroups subsystem, but also include any custom JGroups channels (maybe limited to those channels using the shipped JGroups version to avoid version mismatch complications). -- 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

[ https://issues.jboss.org/browse/AS7-4388?page=com.atlassian.jira.plugin.s... ] Dennis Reed commented on AS7-4388: ---------------------------------- Yes, my argument against the cluster=* section is really that management and clustering should stay orthogonal. Leave the management tasks (including aggregating data across nodes) to the management layer, unrelated to the cluster. I agree that you may care more about data across nodes that interact. But not that it's limited to clustering subsystems. As an example, maybe you'd want to look at the stats of JDBC pools across the cluster (an undersized pool could end up bringing down the cluster). I agree that the functionality is wanted, just at a higher level in the management layer, not specific to clusters or clustering subsystems. I don't have anything against putting the configuration and runtime data near each other. I'm just against the duplication of the same data in different places (more work to maintain, QA, document, support, etc). I'd like to see it in just one place (wherever that is). Sorry, my explanation was kind of vague in this section. What I was specifically referring to was to make sure we show the runtime version of the protocol list and configurations, as opposed to just a copy of the stack= configurations. Quite a few protocol settings could be changed at runtime for a specific channel, and protocols themselves could even be added or removed (don't think we currently do that in AS subsystems, but JGroups supports it). I was mainly referring to any channels used by customer code. We do have a handful of customers using JGroups for other things outside the AS uses. (and that one would really be a "nice to have", certainly not critical). -- 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