[ 
https://issues.apache.org/jira/browse/IGNITE-13815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17247819#comment-17247819
 ] 

Anton Kalashnikov commented on IGNITE-13815:
--------------------------------------------

[~ktkale...@gridgain.com], it looks good to me. I just want to propose to 
rename two methods incMinReserveIndex and incMinLockIndex to something without 
'inc' because 'inc' associated to increment and it is expected the delta as a 
given parameter(or nothing). But in your case, the parameter is not the delta 
but is an absolute value which means it should not be 'inc' it should be 'set'. 
So maybe it is better to rename to setMinReserveIndex or just minReserveIndex. 
In my opinion, it is ok if any other restriction like 'setting only value which 
greater than current' can be described in java-doc rather than name because it 
is anyway impossible to make such an informative name.

> Remove ability to delete segments from the middle of WAL archive
> ----------------------------------------------------------------
>
>                 Key: IGNITE-13815
>                 URL: https://issues.apache.org/jira/browse/IGNITE-13815
>             Project: Ignite
>          Issue Type: Improvement
>          Components: persistence
>            Reporter: Kirill Tkalenko
>            Assignee: Kirill Tkalenko
>            Priority: Major
>             Fix For: 2.10
>
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> At the moment we have the option to delete segments from the middle of the 
> archive via the *FileWriteAheadLogManager#truncate*. This creates gaps in the 
> archive and makes it invalid.
> It should be possible to delete segments sequentially up to the upper 
> boundary. It has also been found that there is no protection against segment 
> deletion, which may be needed for a binary recovery.
> Also need to get rid of the physical check when reserving segments through 
> the *FileWriteAheadLogManager#reserve*.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to