[
https://issues.apache.org/jira/browse/IGNITE-6867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16276014#comment-16276014
]
Vladimir Ozerov commented on IGNITE-6867:
-----------------------------------------
[~alex_pl],
1) The same is true for local node - I can have an attribute on it which
doesn't relate to the cluster. E.g. at some point we might want to expose node
ID, node ports, etc.. How would youк design cope with it? There are three
possible approaches - a) have separate classes - the most correct one as node
and cluster are inherently not it parent-child relation; b) have node extend
cluster - bad enough, but we have somewhat similar approach for
{{IgniteCluster}}, so it would be intuitive for users at the very least; c)
have cluster extend node - the most wrong among the others.
2) Why did you decide to return object without any transformations? AFAIK there
are lots of Object attributes which JMX will simply fail to marshal. Did you
test non-String and non-primitive attributes? IMO correct approach would be to
operate on Strings.
3) Agree. But in any case let's think how to fix these two methods. First, they
are named wrongly. Second, as a user I cannot understand rationale behind them.
E.g. why {{groupNodes}} return integer instead of node IDs? Why can't I get the
list of attribute values? Why client/server and attribute value are chosen as
"dimensions" in such exact way? How about other dimensions from
{{ClusterGroup}} API, such as "forCacheNodes", "forDataNodes", "forNodeIds",
etc.? All these things make API inconsistent. Let's think how to fix it. My
proposal:
{code}
interface ClusterMetricsMXBean {
/* Working with attributes. */
Collection<String> attributeNames();
Collection<String> attributeValues(String attrName);
/* Get node IDs with the given attribute. */
Collection<UUID> nodeIdsForAttribute(String attrName, String attrVal);
Collection<UUID> nodeIdsForAttribute(String attrName, String attrVal,
boolean includeServers, boolean includeClients)
}
{code}
> Implement new JMX metrics for topology monitoring
> -------------------------------------------------
>
> Key: IGNITE-6867
> URL: https://issues.apache.org/jira/browse/IGNITE-6867
> Project: Ignite
> Issue Type: New Feature
> Reporter: Aleksey Plekhanov
> Assignee: Pavel Pereslegin
> Labels: iep-6, jmx
> Fix For: 2.4
>
>
> These additional metrics and methods should be implemented:
> * Current topology version
> * Total server nodes count
> * Total client nodes count
> * Method to count nodes filtered by some node attribute
> * Method to count nodes grouped by some node attribute
>
> There is already a ticket to implement first 2 metrics from this list
> (IGNITE-6844)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
