Re: Configurations precedence and consistency across the cluster

[eugene miretsky <eu...@gmail.com>]

Thanks for the response!

A few more follow up questions:
1) How can we chance configurations of persistent caches (replication and
recovery settings for example)?
2) For client related settings, are the settings taken from the server
config, or client config (partitionLosePolicy or SQL table templates)? Can
I have different policies per client?

Cheers,
Eugene

On Tue, Aug 21, 2018 at 3:26 PM akurbanov <an...@gmail.com> wrote:

> Hello,
>
> 1. No. Cache with configuration specified in xml file will be pre-created
> and won't change if you will try to get it using changed configuration.
> 2. If you are asking about a single node, yes, that is correct.
> 3. You will get an exception on startup in case you have different
> configurations for the same cache.
>
> Caches were not designed to support configuration changes on the fly, you
> should destroy/recreate cache in order to apply configuration change which
> means you should also delete data from the cache. In the future, there will
> be some possibilities to change some configuration parameters in runtime,
> but definitely not the ones responsible for data flow and distribution in
> cluster.
>
> Could you please clarify what are your requirements for cache configuration
> updates?
>
>
>
> --
> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
>

Re: Configurations precedence and consistency across the cluster

[akurbanov <an...@gmail.com>]

Hello,

What is the use-case that are you trying to achieve? What does "to sync
cache configs" mean? 

IgniteCache.withX returns you cache with a given  CacheOperationContext
<https://github.com/apache/ignite/blame/master/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/CacheOperationContext.java>  
that allows you to override several usage patterns from client to client,
the cache itself may be created with XML configuration as well as using Java
API.

Have you tried launching nodes with these configs? Both cases will throw an
exception on startup of a node that is trying to join with cache
configuration different from the already started one.

You may refer to
org.apache.ignite.internal.processors.cache.ClusterCachesInfo#checkCache to
familiarize with configuration checks that will be performed on node startup
in case where you have preconfigured caches in xml.

Regards,
Anton



--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: Configurations precedence and consistency across the cluster

[eugene miretsky <eu...@gmail.com>]

Thanks!

A few clarifications:
1) The first configuration with given cache name will be applied to all
nodes" - what do you mean by the first configuration? The configuration of
the first node that was started? Is there a gossip/consensus  protocol that
syncs the cache configs across the
2) We are using an xml configuration file instead of  IgniteCache.withX.,
will it work similarly?

For example, I have the following configuration files on the client and
server node
1)  What settings will be applied when I create a SQL table with
template test_template from the client?
2)  What will happen if I start another  client with different settings?

*Client:*

<property name="cacheConfiguration">
    <list>
        <bean parent="cache-template">
            <property name="name" value="test_template*"/>
            <property name="cacheMode" value="PARTITIONED"/>
            <property name="atomicityMode" value="ATOMIC"/>
            <property name="copyOnRead" value="true"/>
            <property name="queryDetailMetricsSize" value="10"/>
            <property name="queryParallelism" value="32"/>
            <property name="statisticsEnabled" value="true"/>
            <property name="managementEnabled" value="true"/>

            <property name="rebalanceMode" value="SYNC"/>
            <property name="writeSynchronizationMode" value="FULL_SYNC"/>
            <property name="backups" value="0"/>

        </bean>
    </list>
</property>

*Server*

<property name="cacheConfiguration">
    <list>
        <bean parent="cache-template">
            <property name="name" value="test_template*"/>
            <property name="cacheMode" value="PARTITIONED"/>
            <property name="atomicityMode" value="ATOMIC"/>
            <property name="copyOnRead" value="true"/>
            <property name="queryDetailMetricsSize" value="10"/>
            <property name="queryParallelism" value="1"/>
            <property name="statisticsEnabled" value="true"/>
            <property name="managementEnabled" value="true"/>

            <property name="rebalanceMode" value="ASYNC"/>
            <property name="writeSynchronizationMode" value="FULL_ASYNC"/>
            <property name="backups" value="1"/>

        </bean>
    </list>
</property>



On Tue, Sep 18, 2018 at 10:01 AM akurbanov <an...@gmail.com> wrote:

> Hello Eugene,
>
> 1. Dynamic cache configuration changes are not supported, except properties
> that may be overridden with IgniteCache.withX.
> 2. The first configuration with given cache name will be applied to all
> nodes. You can use the same IgniteCache.withX to put with different expiry
> policies per each client. Also you can configure different near cache
> configurations that will take effect only for operations on client where it
> was configured.
>
> Regards,
> Anton
>
>
>
> --
> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
>

Re: Configurations precedence and consistency across the cluster

[akurbanov <an...@gmail.com>]

Hello Eugene,

1. Dynamic cache configuration changes are not supported, except properties
that may be overridden with IgniteCache.withX.
2. The first configuration with given cache name will be applied to all
nodes. You can use the same IgniteCache.withX to put with different expiry
policies per each client. Also you can configure different near cache
configurations that will take effect only for operations on client where it
was configured.

Regards,
Anton



--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/