[
https://issues.jboss.org/browse/AS7-4388?page=com.atlassian.jira.plugin.s...
]
Richard Achmatowicz commented on AS7-4388:
------------------------------------------
Dennis, thanks for the feedback!
That should already be available in domain mode, or using any other
tool (JON) that looks at multiple nodes.
At least for now, IIUC, a server group and
a cluster are really orthogonal concepts. A server group is a set of servers, which may or
may not be clustered, and a cluster is also a set of servers, which may or may not equate
to a single server group. Whether or not the notion of a cluster as described above is
rejected until such time as it gets integrated into domain mode is another issue
altogether. Brian?
Also, there are already features in the management api (starting/stopping server groups,
deploying to server groups) which look at multiple nodes and also appear in JON. This
would simply be yet another. Not everyone who wants to manage servers as a group need use
JON, right?.
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.
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 general?
I don't think that functionality should be duplicated in a
different way.
Agreed.
Don't duplicate the information already available under stack=!
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). This was the state of
affairs in the old JMX view of channels where the two were integrated. You could see all
configuration elements as well as runtime elements. If you feel its too much, it could be
left out.
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).
This is what is planned - the
channel=* resource's purpose is to expose the runtime info of each channel instance.
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).
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.
Provide clustering management use cases
---------------------------------------
Key: AS7-4388
URL:
https://issues.jboss.org/browse/AS7-4388
Project: Application Server 7
Issue Type: Task
Components: Console
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