ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Denis Magda <dma...@apache.org>
Subject Re: Ignite.close(), G.stop(name, true). Change flag cancel to false
Date Wed, 09 Aug 2017 21:25:25 GMT
I’m totally for the replacement of ‘crashed’ with ‘stopped’. 

As for the waiting of the checkpointing completion I would NOT do it the default behavior
and would rather check the ‘cancel’ flag to make a decision. If the ‘cancel’ is ‘true’
(which is default) then we’re not going to wait for the completion and should print a message
that   ‘cancel’ has to be set to ‘false’ explicitly if the user prefers to wait while
the checkpoint is over before shutting down a node.

—
Denis

> On Aug 4, 2017, at 4:31 AM, Ivan Rakov <ivan.glukos@gmail.com> wrote:
> 
> My vote is still for making message softer (crashed -> stopped) and keeping logic
as is.
> 
> Example with File.close() is good, but I think it's not the case here. The state on disk
after node stop *will not* reflect all user actions made before Ignite.close() call, independent
of whether node was stopped during checkpoint.
> Ignite will recover to actual state anyway, the only difference is WAL replay algorithm
(stopping during checkpoint will force Ignite to replay delta records).
> 
> However, waiting for checkpoint on node stop brings two advantages:
> 1) Next start will be faster - less WAL records to replay.
> 2) Partition files will be locally consistent after node stop. User will be able to save
partition file for any kind of analysis.
> 
> Are they strong enough to force user to wait on stop?
> 
> Best Regards,
> Ivan Rakov
> 
> On 04.08.2017 13:42, Vyacheslav Daradur wrote:
>> Hi guys, I'll just add my opinion if you don't mind.
>> 
>>> May be we should implement Vladimir's suggestion to flush the pages
>> without
>>> respect to the cancel flag? Are there any thoughts on this?
>> I think It's  good suggestion.
>> But in case of unit-testing a developer usually call #stopAllGrids() at the
>> end of all tests.
>> The method GridAbstactTest#stopAllGrids() is built on top of the
>> method G.stop(name,
>> true) including.
>> IMO in that case checkpoints' flushing isn't necessary.
>> 
>> 
>> 2017-08-04 13:25 GMT+03:00 Dmitry Pavlov <dpavlov.spb@gmail.com>:
>> 
>>> Thank you all for replies.
>>> 
>>> I like idea to replace 'crashed' to 'stop'.  'crashed' word is really
>>> confusing.
>>> 
>>> But still, if I call close () on file, all data is flushed to disk. But for
>>> ignite.close () checkpoint may be not finished.
>>> 
>>> May be we should implement Vladimir's suggestion to flush the pages without
>>> respect to the cancel flag? Are there any thoughts on this?
>>> 
>>> пт, 4 авг. 2017 г. в 11:12, Vladimir Ozerov <vozerov@gridgain.com>:
>>> 
>>>> Ivan,
>>>> 
>>>> Hanging on Ignite.close() will confuse user no more than restore on start
>>>> after graceful shutdown. IMO correct approach here would be to:
>>>> 1) wait for checkpoint completion irrespective of "cancel" flag, because
>>>> this flag relates to compute jobs only as per documentation
>>>> 2) print an INFO message to the log that we are saving a checkpoint due
>>> to
>>>> node stop.
>>>> 
>>>> On Fri, Aug 4, 2017 at 10:54 AM, Ivan Rakov <ivan.glukos@gmail.com>
>>> wrote:
>>>>> Dmitriy,
>>>>> 
>>>>> From my point of view, invoking stop(true) is correct behaviour.
>>>>> 
>>>>> Stopping node in the middle of checkpoint is absolutely valid case.
>>>> That's
>>>>> how persistence works - node will restore memory state if stopped at
>>> any
>>>>> moment.
>>>>> On the other hand, checkpoint may last for a long time. Thread hanging
>>> on
>>>>> Ignite.close() may confuse user much more than "crashed in the middle
>>> of
>>>>> checkpoint" message.
>>>>> 
>>>>> Best Regards,
>>>>> Ivan Rakov
>>>>> 
>>>>> 
>>>>> On 03.08.2017 22:34, Dmitry Pavlov wrote:
>>>>> 
>>>>>> Hi Igniters,
>>>>>> 
>>>>>> I’ve created the simplest example using Ignite 2.1 and persistence
>>> (see
>>>>>> the
>>>>>> code below). I've included Ignite instance into try-with-resources
(I
>>>>>> think
>>>>>> it is default approach for AutoCloseable inheritors).
>>>>>> 
>>>>>> But next time when I started this server I got message: “Ignite
node
>>>>>> crashed in the middle of checkpoint. Will restore memory state and
>>>> enforce
>>>>>> checkpoint on node start.”
>>>>>> 
>>>>>> This happens because in close() method we don’t wait checkpoint
to
>>> end.
>>>> I
>>>>>> am afraid this behaviour may confuse users on the first use of the
>>>>>> product.
>>>>>> 
>>>>>> What do you think if we change Ignite.close() functioning from
>>>> stop(true)
>>>>>> to stop(false)? This will allow to wait checkpoints to finish by
>>>> default.
>>>>>> Alternatively, we may improve example to show how to shutdown server
>>>> node
>>>>>> correctly. Current PersistentStoreExample does not cover server node
>>>>>> shutdown.
>>>>>> 
>>>>>> Any concerns on close() method change?
>>>>>> 
>>>>>> Sincerely,
>>>>>> Dmitriy Pavlov
>>>>>> 
>>>>>> 
>>>>>> IgniteConfiguration cfg = new IgniteConfiguration();
>>>>>> cfg.setPersistentStoreConfiguration(new
>>> PersistentStoreConfiguration());
>>>>>> try (Ignite ignite = Ignition.start(cfg)){
>>>>>>     ignite.active(true);
>>>>>>     IgniteCache<String, String> cache = ignite.getOrCreateCache("test"
>>> );
>>>>>>     for (int i = 0; i < 1000; i++)
>>>>>>           cache.put("Key" + i, "Value" + i);
>>>>>> }
>>>>>> 
>>>>>> 
>> 
>> 
> 


Mime
View raw message