On Wed, Dec 9, 2015 at 6:07 AM, Alexey Kuznetsov
wrote:
> Alex,
>
> Thanks for your suggestions. We will generate server cache configs + client
> near cache configs.
>
Sounds good. Let’s make sure we name them properly, so users will clearly
understand which one is for what.
>
> On Wed, Dec 9,
Alex,
Thanks for your suggestions. We will generate server cache configs + client
near cache configs.
On Wed, Dec 9, 2015 at 9:06 PM, Alexey Kuznetsov
wrote:
> Yakov, Ignite console has UI (on Summary page) for near cache
> configuration with optional eviction policy.
>
> On Wed, Dec 9, 2015 at
Yakov, Ignite console has UI (on Summary page) for near cache configuration
with optional eviction policy.
On Wed, Dec 9, 2015 at 7:34 PM, Yakov Zhdanov wrote:
> I think it is very good idea to generate client node config as well and it
> seems that console should provide ability to configure ne
I see nothing wrong with generating a server config for a client node. This
may be used in a case when server nodes are started with plain empty config
and clients are deploying caches to the grid.
I think it is very good idea to generate client node config as well and it
seems that console should provide ability to configure near cache (e.g.
start size and eviction policy) or turn it off completely.
--Yakov
2015-12-09 10:07 GMT+03:00 Alexey Kuznetsov :
> I'm working on Ignite Web Console.
I'm working on Ignite Web Console.
And this utility is generating XML and java code with cluster configuration.
For server-side I generate XML and java code that describe caches.
But should I do the same when generating client node configuration?
I think that I should only generate NearCacheConf
