You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ignite.apache.org by Sergey Antonov <an...@gmail.com> on 2019/11/25 11:56:13 UTC
Re: [DISCUSSION] Single point in API for changing cluster state.
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.scherbakoff@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 <an...@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 <an...@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
> > > <ag...@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.scherbakoff@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 <
> antonovsergey93@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 <mm...@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 <
> > >> antonovsergey93@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.mashenkov@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 <
> > >> > > antonovsergey93@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 <
> > >> > > antonovsergey93@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
Re: [DISCUSSION] Single point in API for changing cluster state.
Posted by Sergey Antonov <an...@gmail.com>.
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 <an...@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.scherbakoff@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 <an...@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 <antonovsergey93@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
>> > > <ag...@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.scherbakoff@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 <
>> antonovsergey93@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 <mm...@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 <
>> > >> antonovsergey93@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.mashenkov@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 <
>> > >> > > antonovsergey93@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 <
>> > >> > > antonovsergey93@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