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/12/25 12:53:42 UTC
Re: [DISCUSSION] Single point in API for changing cluster state.
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