Dennis Reed commented on AS7-4388:
At least for now, IIUC, a server group and a cluster are really
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.
Hmm. I think the need is greater when the nodes interact - as in a
cluster - where the behaviour of one node can directly impact the other.
So can we say this applies to all clustering subsystems, as opposed to subsystems in
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.
The only reason for duplicating the configuration info was to avoid
the user having to swap back and forth between the configuration
for a channel (in the stack=* resource) and the runtime information for the channel (in
the channel=* resource).
I don't have anything against putting the configuration and runtime data near each
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).
This is what is planned - the channel=* resource's purpose is to
expose the runtime info of each channel instance.
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).
IIUC, only EJB, ISPN and other clustering subsystems should be
creating channels and this is done via the ChannelFactoryService.
The channel=* resources will expose all channels so created.
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).
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