ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ivan Rakov <ivan.glu...@gmail.com>
Subject Re: Clusterwide settings validation
Date Tue, 10 Jul 2018 10:42:08 GMT
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 nodes 
(page size, tx configuration): GridCacheProcessor#checkConsistency.
We also match necessary part of CacheConfiguration between nodes in 
GridCacheUtils#checkAttributeMismatch method.

Does anyone know another properties mismatch of which can backfire on us?

Best Regards,
Ivan Rakov

On 10.07.2018 10:47, Andrew Medvedev wrote:
> 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 memPlcName and getDataRegionName()), so inclusion
> pattern ("get all properties") does not work quite well with them
>
> 2) If using manual handling of getter methods, we see that a lot of
> metrics are returned by methods in CacheConfiguration and below,
> instead of properties (in TcpCommunicationSpi especially), and getter
> methods are not properly annotated. (for ex see
> https://issues.apache.org/jira/browse/IGNITE-8829), so exclusion
> pattern ("get all except metrics etc") forces us to manually exclude
> those, not quite well too, looks like a hack
>
> Plus some properties, although configurable, have their defaults
> dynamically set on startup for ex. DFLT_MEMORY_POLICY_MAX_SIZE
>
> Just to make sure, we compare with coordinator, log locally, and
> client nodes are excluded?
>
> On Fri, Jul 6, 2018 at 4:15 PM, Yakov Zhdanov <yzhdanov@gridgain.com> wrote:
>> 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 <andrew.y.medvedev@gmail.com>:
>>
>>> 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 <nizhikov@apache.org>
>>> wrote:
>>>> 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.
>>>> [1] https://github.com/apache/ignite/blob/master/modules/
>>> core/src/main/java/org/apache/ignite/internal/IgniteKernal.java#L825
>>>> [2] https://github.com/apache/ignite/blob/master/modules/
>>> core/src/main/java/org/apache/ignite/internal/GridComponent.java#L153
>>>> В Ср, 04/07/2018 в 08:58 +0300, Andrew Medvedev пишет:
>>>>> 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 each node itself on start/joining topology/etc..
>>>>>
>>>>> 1) Is his needed?
>>>>> 2) Have the implementation details been discussed somewhere?
>>>>>
>>>>> Cheers


Mime
View raw message