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
- addition of cluster-related information and operations (cluster membership, shared
transport, other cluster-specific operations)
1.1 For JGroups:
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.
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
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
1.2 For Infinispan
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.
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).
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
Provide clustering management use cases
Project: Application Server 7
Issue Type: Task
Reporter: Heiko Braun
Assignee: Bela Ban
Fix For: 7.2.0.CR1
In order to prep the UI, we would need a list of typical clustering management use cases.
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