Hi guys,
DataStorageConfiguration#getMetricsSubIntervalCount was added by me as
last resort to decrease number of intervals in HitRateMetrics in case of
unexpected negative performance impact. As far as I know, no one ever
used it - the precaution appeared to be premature. We can disregard
Andrey Gura created IGNITE-12045:
Summary: [IEP-35] JmxExporterSpi has too broad name.
Key: IGNITE-12045
URL: https://issues.apache.org/jira/browse/IGNITE-12045
Project: Ignite
Issue Type:
Andrey Gura created IGNITE-12044:
Summary: [IEP-35] JmxExporterSpi displays histogram values
incorrectly
Key: IGNITE-12044
URL: https://issues.apache.org/jira/browse/IGNITE-12044
Project: Ignite
Hello, Andrey.
> Not necessary if we have exponential bounds' values for histograms.
What do you mean by "exponential bounds"?
> Anyway, in current solution it looks ugly and not usable.
Thanks, for the feedback, appreciate you ownesty.
> No. But we should admit that this is bad decision and
Nikolay,
> Filters based of hostname or ip address.
Hostname or IP address can be injected to Ignite configuration as labels
(NodeAttributes) without dynamic lookup necessary.
> I don't think we should take "hard to implement" as an argument in this
discussion :)
> Seems, whole Ignite peer
>> - metric configuration is node local (not cluster wide).
> This issue is easy to solve on the user-side and in Ignite core.
It's imaginary simplicity. The first, you need some additional
automation on user-side in order to configure all nodes of the
cluster. The second, new nodes can join to
Pavel.
> I don't see yet any practical cases with NodeFilter that can't be resolved
> using just labels.
Filters based of hostname or ip address.
> 1. User-defined node filter classes must be deployed on all nodes whether
> or nor they required on them. This increases the complexity of
Nikolay,
Thank you for your feedback.
Could you please tell more about cases when custom node filter that not
relies on node attributes may be used?
For me, it's flexibility just for flexibility that introduces problems
described in the topic.
I don't see yet any practical cases with NodeFilter
Pavel Kuznetsov created IGNITE-12043:
Summary: Metrics: JMX exporter reports incorrect description.
Key: IGNITE-12043
URL: https://issues.apache.org/jira/browse/IGNITE-12043
Project: Ignite
Hello, Andrey.
> - metric configuration is node local (not cluster wide).
This issue is easy to solve on the user-side and in Ignite core.
> - metric configuration doesn't survive node restart.
We decide to go with the simplest solution, for now.
The easiest solution was implemented.
Do we
Igniters,
I've took a look to the PR and I want follow up this discussion again.
Proposed solution has a couple of significant drawbacks:
- metric configuration is node local (not cluster wide).
- metric configuration doesn't survive node restart.
This drawbacks make configuration complex,
Ivan,
~Mail~ Talks are cheap! Show me the code (C) :)
class NodeAttributeFilter implements IgnitePredicate {
private String name;
private T value;
public boolean apply(ClusterNode n) {
return Objects.equals(n.attribute(name), value);
}
Hi Nikolay,
Could you please elaborate how will NodeAttributeFilter behave? Do you
mean specifying attribute name and value for exact comparison inside?
Without any dynamic (user) code involved?
Also I it is quite interesting for me what flexibility you are
thinking about? I think that the topic
Hello, Pavel.
I think we shouldn't reduce flexibility of NodeFilter.
So, I am -1 to remove it in Ignite 3.
Instead, Ignite can provide NodeAttributeFilter implementation of NodeFilter.
Seems, it will resolve all described issues.
В Чт, 01/08/2019 в 19:33 +0300, Ilya Kasnacheev пишет:
> Hello!
Maxim, I fixed issue, which you found above. Look
at
org.apache.ignite.internal.processors.cache.ClusterReadOnlyModeTest#testDataStreamerReadOnlyConcurrent*
tests.
вт, 4 июн. 2019 г. в 15:58, Maxim Muzafarov :
> >> We throw CacheException on each update to read-only cluster. User code
> must
15 matches
Mail list logo
