BTW, I have added a ticket for the configuration template [1] and linked it
to the ticket originally created by Yakov [2].
[1] https://issues.apache.org/jira/browse/IGNITE-8986
[2] https://issues.apache.org/jira/browse/IGNITE-8951
D.
On Wed, Jul 11, 2018 at 6:58 PM, Yakov Zhdanov wrote:
> Ivan
Ivan, yes. We can go with reflection through configuration and SPIs and,
you are rigth, suppressed list should be manually defined.
--Yakov
What about an idea to have a validation template file (e.g.
ignite-validate.xml), and make sure on startup that all config properties
specified in that file match. This way a user could put this file somewhere
on a shared network drive and have an extra degree of confidence that the
configuration i
Slava,
I agree. Different persistence enabled flag can cause unpleasant issues.
I've left a comment in IGNITE-8951.
Yakov,
Seems like I misunderstood the point of the discussion from the very
beginning. I thought that Andrew raised topic to discuss adding new
checks that will fail node join
.Hello Ivan,
I think it would be nice to add validation
DataRegionConfiguration#persistenceEnabled property. That property must be
the same across a cluster for the given data region.
Perhaps, different values of `initSize`, `maxSize` etc make sense in case
of a heterogeneous cluster, except `per
Ivan, I would think of some test that will randomly generate configs for
nodes and run some logic.
--Yakov
Guys,
For your information: rebalanceThreadPoolSize validation is already
implemented and merged to master:
https://issues.apache.org/jira/browse/IGNITE-8904
You can overview the commit to see the approach. By the way, we already
validate some other parameters that can't differ among cluster n
Made comment there, c&p here as well
Is it going to be a preconfigured set of settings, or a whole range
of settings?
If latter :
1) Property names in CacheConfiguration do not always correspond to
getters (some follow different naming conventions, some are completely
different, as in memPlcNam
Guys, I created ticket for config params validation -
https://issues.apache.org/jira/browse/IGNITE-8951. Feel free to comment.
Yakov Zhdanov
www.gridgain.com
2018-07-04 10:51 GMT+03:00 Andrew Medvedev :
> Hi Nikolay
>
> No, we have been beaten by
> https://issues.apache.org/jira/browse/IGNITE-89
Hi Nikolay
No, we have been beaten by
https://issues.apache.org/jira/browse/IGNITE-8904?jql=text%20~%20%22rebalanceThreadPoolSize%22
it is not checked on start
Utility I mean check
org.apache.ignite.configuration.IgniteConfiguration and children
On Wed, Jul 4, 2018 at 10:36 AM, Nikolay Izhikov
Hello, Andrew.
Can you clarify your question?
What checks do you mean, exactly?
Do you mean internal Ignite checks or user-provided checks?
Ignite checks configuration consistency on node start [1].
Ignite do have consistency check for a joining node. Take a look at [2] and all
of it children.
Hello everybody
Our company has lots of nodes in cluster, and we have seen some
problems with inconsistent settings on nodes clusterwide. To help us
with this, we made an utility to check consistency of settings on
running cluster, but it is a hack, better ways seems to be settings
validation by e
12 matches
Mail list logo
