Igniters, ticket[1] in patch available state. Anybody want to review changes?
[1] https://issues.apache.org/jira/browse/IGNITE-12225 пн, 25 нояб. 2019 г. в 14:56, Sergey Antonov <antonovserge...@gmail.com>: > Alexei Scherbakov, > > > After activation (in read-only mode or not) rebalancing is possible to > begin and the grid will not be free of updates until it's finished. So the > grid will not be in truly read-only mode even if cache updates are > prohibited. Probably it would be enough just wait until rebalancing is > finished before releasing future. > I'm afraid, we can't guarantee truly read-only mode due to TTL on cache > entries > > > I do not understand the necessity of handling states comparison on > transition. Why not just return current(previous) state ? Could you give > more detailed explanation for this ? > User could face the unexpected behaviour, If we always return current > state (target state of transition) or previous state (initial state of > transition). For example, transition from INACTIVE to ACTIVE and we return > current state. User gets cluster state (ACTIVE) and tries to get cache, but > activation has not been completed yet. User will get exception, but cluster > state returns ACTIVE value. So, we can't always return current state. > Another example: transition from ACTIVE to READ_ONLY and we return > previous state. User gets cluster state (ACTIVE) and tries to update value > in cache. User could get ClusterReadOnlyModeException in this case. > So we should return state with lower functionality from previous and > current states for avoiding unexpected behaviour. > > > > чт, 31 окт. 2019 г. в 18:24, Alexei Scherbakov < > alexey.scherbak...@gmail.com>: > >> Sergey Antonov, >> >> > Read-only mode doesn't affects rebalance process. >> After activation (in read-only mode or not) rebalancing is possible to >> begin and the grid will not be free of updates until it's finished. >> So the grid will not be in truly read-only mode even if cache updates are >> prohibited. Probably it would be enough just wait until rebalancing is >> finished before releasing future. >> >> > How about INACTIVE, ACTIVE, ACTIVE_READ-ONLY states? >> INACTIVE, READ_WRITE, READ_ONLY seems more appropriate for ClusterState. >> >> I do not understand the necessity of handling states comparison on >> transition. Why not just return current(previous) state ? Could you give >> more detailed explanation for this ? >> >> вт, 29 окт. 2019 г. в 14:25, Sergey Antonov <antonovserge...@gmail.com>: >> >> > He, Igniters! >> > >> > I'd like to share some points encountered during work on ticket [1]: >> > >> > - I added property clusterStateOnStart with type ClusterState to >> > IgniteConfiguration. The property will be analogue of activeOnStart. >> > Default value of the property will be ACTIVE for keeping defalut >> value >> > consistency. Also I marked property activeOnStart as deprecated. >> > - I introduced order on values of ClusterState. It needs for user >> > friendly behaviour during cluster state transition. If cluster is >> > changing >> > state from state_A to state_B and user is requesting current cluster >> > state without waiting end of transition we must return lesser of two >> > states: state_A and state_B. I think the order must be: ACTIVE > >> > READ_ONLY > INACTIVE. Examples (state_A -> state_B = response on the >> > users cluster state request during transition): >> > - ACTIVE -> INACTIVE = INACTIVE (Now we have this behavior) >> > - INACTIVE -> ACTIVE = INACTIVE (Now we have this behavior) >> > - ACTIVE -> READ_ONLY = READ_ONLY >> > - READ_ONLY -> ACTIVE = READ_ONLY >> > - READ_ONLY -> INACTIVE = INACTIVE >> > - INACTIVE -> READ_ONLY = INACTIVE >> > >> > I'd like to know your opinion about my points. What do you think about >> it? >> > >> > [1] https://issues.apache.org/jira/browse/IGNITE-12225 >> > >> > >> > вт, 15 окт. 2019 г. в 14:56, Sergey Antonov <antonovserge...@gmail.com >> >: >> > >> > > Hi, Alexei! >> > > >> > > Thank you for reply! >> > > >> > > > The states ACTIVE, INACTIVE, READ-ONLY look confusing. Actually >> > > read-only cluster is active too. >> > > How about INACTIVE, ACTIVE, ACTIVE_READ-ONLY states? >> > > >> > > > Also it would be useful to allow users wait for re-balance which >> could >> > > happen after activation in read-only mode to achieve really idle grid. >> > > Read-only mode doesn't affects rebalance process. >> > > >> > > > I would suggest adding new property to Ignite configuration like >> > > setActivationOptions(ActivationOption... options) which should be >> mutable >> > > in runtime. >> > > I'm not sure that it's good idea. @Alexey Goncharuk >> > > <agoncha...@apache.org> I'd like to know your opinion about >> activation >> > > option and storing them on PDS. >> > > >> > > > This proposal also better regarding backward compatibility. >> > > Which kind of compatibility did you mean? New cluster mode doesn't >> > affects >> > > PDS compatibility. >> > > >> > > ср, 25 сент. 2019 г. в 13:26, Alexei Scherbakov < >> > > alexey.scherbak...@gmail.com>: >> > > >> > >> Sergey Antonov, >> > >> >> > >> The states ACTIVE, INACTIVE, READ-ONLY look confusing. >> > >> Actually read-only cluster is active too. >> > >> >> > >> I would suggest adding new property to Ignite configuration like >> > >> setActivationOptions(ActivationOption... options) which should be >> > mutable >> > >> in runtime. >> > >> >> > >> For control.sh should be the same options for activate command. >> > >> >> > >> Also it would be useful to allow users wait for re-balance which >> could >> > >> happen after activation in read-only mode to achieve really idle >> grid. >> > >> >> > >> So, available options list in my opinion: READ_ONLY, >> WAIT_FOR_REBALANCE. >> > >> >> > >> This proposal also better regarding backward compatibility. >> > >> >> > >> вт, 24 сент. 2019 г. в 20:35, Sergey Antonov < >> antonovserge...@gmail.com >> > >: >> > >> >> > >> > Maxim, >> > >> > >> > >> > > I think from the user point the INACTIVE -> READ-ONLY transition >> [1] >> > >> > should be allowed prior to adding a new `state` command [2] to >> avoid >> > >> > unnecessary error messages. >> > >> > Yes. I plan complete both tickets till the code freeze of 2.8 >> release. >> > >> > >> > >> > > I also think we can avoid the word 'set` in this command. >> > >> > I don't think so. We already have command control.sh --state >> command >> > for >> > >> > getting current state. I think we shouldn't "overload" commands in >> > >> > control.sh. >> > >> > >> > >> > > What about cluster deactivation confirmation? Will it be used for >> > all >> > >> the >> > >> > cluster state changes? >> > >> > Yes. I think we should confirm any cluster state transition. >> > >> > >> > >> > вт, 24 сент. 2019 г. в 19:07, Maxim Muzafarov <mmu...@apache.org>: >> > >> > >> > >> > > Sergey, >> > >> > > >> > >> > > +1, I like your idea. >> > >> > > >> > >> > > I think from the user point the INACTIVE -> READ-ONLY transition >> [1] >> > >> > > should be allowed prior to adding a new `state` command [2] to >> avoid >> > >> > > unnecessary error messages. I also think we can avoid the word >> 'set` >> > >> > > in this command. >> > >> > > >> > >> > > Example: control.sh --state ACTIVE [--yes] >> > >> > > >> > >> > > >> > >> > > What about cluster deactivation confirmation? Will it be used for >> > all >> > >> > > the cluster state changes? >> > >> > > Deactivate cluster: >> > >> > > control.(sh|bat) --deactivate [--yes] >> > >> > > >> > >> > > >> > >> > > [1] https://issues.apache.org/jira/browse/IGNITE-11866 >> > >> > > [2] https://issues.apache.org/jira/browse/IGNITE-12225 >> > >> > > >> > >> > > >> > >> > > >> > >> > > On Tue, 24 Sep 2019 at 16:50, Sergey Antonov < >> > >> antonovserge...@gmail.com> >> > >> > > wrote: >> > >> > > > >> > >> > > > Andrey, >> > >> > > > >> > >> > > > > What are state transitions valid? >> > >> > > > Now all transitions are valid, except INACTIVE -> READ-ONLY. >> This >> > >> > > > transition will be fixed under [1] >> > >> > > > >> > >> > > > > Regarding state names, as I understand, all transitions are >> > valid >> > >> > from >> > >> > > > any to any of 3 states. >> > >> > > > Yes, see my comment above. >> > >> > > > >> > >> > > > > But, regarding on console.sh command it is not obvious. >> > >> > > > Yes. It's one of points why we should have single command in >> > >> > control.sh. >> > >> > > > >> > >> > > > > What effect will --read-only-on and --read-only-off commands >> > have >> > >> if >> > >> > > > current state is INACTIVE ? >> > >> > > > --read-only-on - cluster will be activated in read-only mode >> > >> > > > --read-only-off - cluster will be activated. I.e >> --read-only-off >> > >> will >> > >> > > have >> > >> > > > the same effect as --activate >> > >> > > > [1] https://issues.apache.org/jira/browse/IGNITE-11866 >> > >> > > > >> > >> > > > вт, 24 сент. 2019 г. в 16:40, Andrey Mashenkov < >> > >> > > andrey.mashen...@gmail.com>: >> > >> > > > >> > >> > > > > Sergey, >> > >> > > > > >> > >> > > > > What are state transitions valid? >> > >> > > > > For now we have only 2 states (active and inactive) and >> possible >> > >> > > > > transitions are obvious Active <--> Inactive. >> > >> > > > > >> > >> > > > > Regarding state names, as I understand, all transitions are >> > valid >> > >> > from >> > >> > > any >> > >> > > > > to any of 3 states. >> > >> > > > > But, regarding on console.sh command it is not obvious. >> > >> > > > > What effect will --read-only-on and --read-only-off commands >> > have >> > >> if >> > >> > > > > current state is INACTIVE ? >> > >> > > > > >> > >> > > > > >> > >> > > > > On Tue, Sep 24, 2019 at 4:23 PM Sergey Antonov < >> > >> > > antonovserge...@gmail.com> >> > >> > > > > wrote: >> > >> > > > > >> > >> > > > > > Also, I would add IGNITE-12225 >> > >> > > > > > <https://issues.apache.org/jira/browse/IGNITE-12225> >> ticket >> > to >> > >> 2.8 >> > >> > > > > release >> > >> > > > > > scope. >> > >> > > > > > >> > >> > > > > > вт, 24 сент. 2019 г. в 16:18, Sergey Antonov < >> > >> > > antonovserge...@gmail.com >> > >> > > > > >: >> > >> > > > > > >> > >> > > > > > > Hi, Igniters! >> > >> > > > > > > >> > >> > > > > > > We have 3 cluster states at the moment: inactive, active, >> > >> > > read-only. >> > >> > > > > > > >> > >> > > > > > > For getting current cluster state and changing them >> > >> IgniteCluster >> > >> > > has >> > >> > > > > > > methods: >> > >> > > > > > > >> > >> > > > > > > - boolean active(), void active(boolean active) - for >> > >> cluster >> > >> > > > > > > activation/deactivation >> > >> > > > > > > - boolean readOnly(), void readOnly(boolean readOnly) >> - >> > for >> > >> > > > > > > enabling/disabling read-only mode. >> > >> > > > > > > >> > >> > > > > > > Also we have control.sh commans for changing cluster >> state: >> > >> > > > > > > >> > >> > > > > > > - --activate >> > >> > > > > > > - --deactivate >> > >> > > > > > > - --read-only-on >> > >> > > > > > > - --read-only-off >> > >> > > > > > > >> > >> > > > > > > For me current API looks unuseful. My proposal: >> > >> > > > > > > >> > >> > > > > > > 1. Create enum ClusterState with values ACTIVE, >> INACTIVE, >> > >> > > READ-ONLY. >> > >> > > > > > > 2. Add methods to IgniteCluster: >> > >> > > > > > > - ClusterState state() returns current cluster >> state >> > >> > > > > > > - void state(ClusterState newState) changes cluster >> > >> state >> > >> > to >> > >> > > > > > > newState state >> > >> > > > > > > 3. Mark as deprecated the following methods in >> > >> IgniteCluster: >> > >> > > > > boolean >> > >> > > > > > > active(), void active(boolean active), >> > >> > > > > > > 4. Add new command to control.sh: control.sh >> --set-state >> > >> > > > > > > (ACTIVE|INACTIVE|READ-ONLY) >> > >> > > > > > > 5. Add warn message that command is depricated in >> > >> control.sh. >> > >> > > > > > > Commands: --activate, --deactivate, --read-only-on, >> > >> > > --read-only-off >> > >> > > > > > > >> > >> > > > > > > >> > >> > > > > > > I created ticket [1] in Jira for it. >> > >> > > > > > > >> > >> > > > > > > What do you think about my proposal? >> > >> > > > > > > >> > >> > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-12225 >> > >> > > > > > > -- >> > >> > > > > > > BR, Sergey Antonov >> > >> > > > > > > >> > >> > > > > > >> > >> > > > > > >> > >> > > > > > -- >> > >> > > > > > BR, Sergey Antonov >> > >> > > > > > >> > >> > > > > >> > >> > > > > >> > >> > > > > -- >> > >> > > > > Best regards, >> > >> > > > > Andrey V. Mashenkov >> > >> > > > > >> > >> > > > >> > >> > > > >> > >> > > > -- >> > >> > > > BR, Sergey Antonov >> > >> > > >> > >> > >> > >> > >> > >> > -- >> > >> > BR, Sergey Antonov >> > >> > >> > >> >> > >> >> > >> -- >> > >> >> > >> Best regards, >> > >> Alexei Scherbakov >> > >> >> > > >> > > >> > > -- >> > > BR, Sergey Antonov >> > > >> > >> > >> > -- >> > BR, Sergey Antonov >> > >> >> >> -- >> >> Best regards, >> Alexei Scherbakov >> > > > -- > BR, Sergey Antonov > -- BR, Sergey Antonov
