ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Valentin Kulichenko <valentin.kuliche...@gmail.com>
Subject Re: about AtomicConfiguration
Date Thu, 14 Jan 2016 04:09:05 GMT

This behavior is correct and unfortunately your suggestion is not going to
work. We create only one cache for all atomic structures, so you can't pass
new configuration for each created atomic. It makes perfect sense to define
all parameters that are not specific for a particular atomic during the
node startup.

As for the error message and the consistency check, I think the message is
very confusing. And the ticket for this already exists for a while [1].
It's assigned to me right now, but if you're interested, feel free to
assign to yourself and provide a patch.

[1] https://issues.apache.org/jira/browse/IGNITE-2096


On Wed, Jan 13, 2016 at 5:09 AM, 李玉珏@163 <18624049226@163.com> wrote:

> Hi:
> About AtomicConfiguration, I found the following issue:
> Configuration of node 1:
> AtomicConfiguration atomicCfg = new AtomicConfiguration();
> atomicCfg.setBackups(1);
> atomicCfg.setAtomicSequenceReserveSize(0);
> IgniteConfiguration cfg = new IgniteConfiguration();
> cfg.setAtomicConfiguration(atomicCfg);
> Ignite ignite = Ignition.start(cfg);
> Configuration of node 2:
> Ignite ignite = Ignition.start();
> Then there will be the following error:
> Only two nodes are configured in the same configuration to successfully
> start up。
> AtomicConfiguration is the global configuration of the start, can not be
> set dynamically after the start, and can not be set for a single sequence。
> CacheConfiguration can be configured separately, and can be dynamically
> configured by ignite.getOrCreateCache(CacheConfiguration) after startup.
> I think AtomicConfiguration's design is not reasonable。
> I propose to merge the three parameters of the atomicSequence method with
> the AtomicConfiguration, and then add one:
> Ignite.atomicSequence (AtomicConfiguration) method.
> Or communitity can consider a more elegant approach.

  • Unnamed multipart/related (inline, None, 0 bytes)
View raw message