Apache Ignite Developers - Legacy Mail Archive

Getting rid of NONE cache rebalance mode

Classic

List

Threaded

10 messages Options

Alexey Goncharuk

Getting rid of NONE cache rebalance mode

Igniters,

I would like to run the idea of deprecating and probably ignoring the NONE
rebalance mode by the community. It's in the removal list for Ignite 3.0
[1], but it looks like it still confuses and creates issues for users [2].

What about deprecating it in one of the next releases and even ignoring
this constant in further releases, interpreting it as ASYNC, before Ignite
3.0? I find it hard to believe that any Ignite user actually has
RebalanceMode.NONE set in their configuration due to its absolutely
unpredictable behavior.

Thanks for your thoughts,
--AG

[1]
https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0+Wishlist
[2]
http://apache-ignite-developers.2346864.n4.nabble.com/About-Rebalance-Mode-SYNC-amp-NONE-td47279.html

Pavel Tupitsyn

Re: Getting rid of NONE cache rebalance mode

+1

More evidence:
https://stackoverflow.com/questions/62902640/apache-ignite-cacherebalancemode-is-not-respected-by-nodes

On Mon, Jul 20, 2020 at 8:26 PM Alexey Goncharuk <[hidden email]>
wrote:

> Igniters,
>
> I would like to run the idea of deprecating and probably ignoring the NONE
> rebalance mode by the community. It's in the removal list for Ignite 3.0
> [1], but it looks like it still confuses and creates issues for users [2].
>
> What about deprecating it in one of the next releases and even ignoring
> this constant in further releases, interpreting it as ASYNC, before Ignite
> 3.0? I find it hard to believe that any Ignite user actually has
> RebalanceMode.NONE set in their configuration due to its absolutely
> unpredictable behavior.
>
> Thanks for your thoughts,
> --AG
>
> [1]
>
> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0+Wishlist
> [2]
>
> http://apache-ignite-developers.2346864.n4.nabble.com/About-Rebalance-Mode-SYNC-amp-NONE-td47279.html
>

Ivan Pavlukhin

Re: Getting rid of NONE cache rebalance mode

Alexey, Igniters,

Could you please outline motivation answering following questions?
1. Does this mode generally work correctly today?
2. Can this mode be useful at all?

I can imagine that it might be useful in a transparent caching use
case (if I did not misunderstand).

2020-07-20 20:39 GMT+03:00, Pavel Tupitsyn <[hidden email]>:

> +1
>
> More evidence:
> https://stackoverflow.com/questions/62902640/apache-ignite-cacherebalancemode-is-not-respected-by-nodes
>
> On Mon, Jul 20, 2020 at 8:26 PM Alexey Goncharuk
> <[hidden email]>
> wrote:
>
>> Igniters,
>>
>> I would like to run the idea of deprecating and probably ignoring the
>> NONE
>> rebalance mode by the community. It's in the removal list for Ignite 3.0
>> [1], but it looks like it still confuses and creates issues for users
>> [2].
>>
>> What about deprecating it in one of the next releases and even ignoring
>> this constant in further releases, interpreting it as ASYNC, before
>> Ignite
>> 3.0? I find it hard to believe that any Ignite user actually has
>> RebalanceMode.NONE set in their configuration due to its absolutely
>> unpredictable behavior.
>>
>> Thanks for your thoughts,
>> --AG
>>
>> [1]
>>
>> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0+Wishlist
>> [2]
>>
>> http://apache-ignite-developers.2346864.n4.nabble.com/About-Rebalance-Mode-SYNC-amp-NONE-td47279.html
>>
>

--

Best regards,
Ivan Pavlukhin

Valentin Kulichenko

Re: Getting rid of NONE cache rebalance mode

+1 for deprecating/removing NONE mode.

Alexey, what do you think about the SYNC mode? In my experience, it does
not add much value as well. I would go as far as removing the
rebalancingMode parameter altogether (probably in 3.0).

-Val

On Mon, Jul 20, 2020 at 11:09 AM Ivan Pavlukhin <[hidden email]> wrote:

> Alexey, Igniters,
>
> Could you please outline motivation answering following questions?
> 1. Does this mode generally work correctly today?
> 2. Can this mode be useful at all?
>
> I can imagine that it might be useful in a transparent caching use
> case (if I did not misunderstand).
>
> 2020-07-20 20:39 GMT+03:00, Pavel Tupitsyn <[hidden email]>:
> > +1
> >
> > More evidence:
> >
> https://stackoverflow.com/questions/62902640/apache-ignite-cacherebalancemode-is-not-respected-by-nodes
> >
> > On Mon, Jul 20, 2020 at 8:26 PM Alexey Goncharuk
> > <[hidden email]>
> > wrote:
> >
> >> Igniters,
> >>
> >> I would like to run the idea of deprecating and probably ignoring the
> >> NONE
> >> rebalance mode by the community. It's in the removal list for Ignite 3.0
> >> [1], but it looks like it still confuses and creates issues for users
> >> [2].
> >>
> >> What about deprecating it in one of the next releases and even ignoring
> >> this constant in further releases, interpreting it as ASYNC, before
> >> Ignite
> >> 3.0? I find it hard to believe that any Ignite user actually has
> >> RebalanceMode.NONE set in their configuration due to its absolutely
> >> unpredictable behavior.
> >>
> >> Thanks for your thoughts,
> >> --AG
> >>
> >> [1]
> >>
> >>
> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0+Wishlist
> >> [2]
> >>
> >>
> http://apache-ignite-developers.2346864.n4.nabble.com/About-Rebalance-Mode-SYNC-amp-NONE-td47279.html
> >>
> >
>
>
> --
>
> Best regards,
> Ivan Pavlukhin
>

Alexey Goncharuk

Re: Getting rid of NONE cache rebalance mode

Ivan,

In my understanding this mode does not work at all even in the presence of
ForceKeysRequest which is now supposed to fetch values from peers in case
of a miss. In this mode we 1) move partitions to OWNING state
unconditionally, and 2) choose an arbitrary OWNING node for force keys
request. Therefore, after a user started two additional nodes in a cluster,
the request may be mapped to a node which does not hold any data. We will
do a read-through in this case, but it will result in significant load
increase on a third-party storage right after a node started, which means
that adding a node will increase, not decrease, the load on the database
being cached.
All these issues go away when (A)SYNC mode is used.

Val,
The idea makes sense to me - a user can use rebalance future to wait for
rebalance to finish. This will simplify the configuration even further.

пн, 20 июл. 2020 г. в 21:27, Valentin Kulichenko <
[hidden email]>:

> +1 for deprecating/removing NONE mode.
>
> Alexey, what do you think about the SYNC mode? In my experience, it does
> not add much value as well. I would go as far as removing the
> rebalancingMode parameter altogether (probably in 3.0).
>
> -Val
>
> On Mon, Jul 20, 2020 at 11:09 AM Ivan Pavlukhin <[hidden email]>
> wrote:
>
> > Alexey, Igniters,
> >
> > Could you please outline motivation answering following questions?
> > 1. Does this mode generally work correctly today?
> > 2. Can this mode be useful at all?
> >
> > I can imagine that it might be useful in a transparent caching use
> > case (if I did not misunderstand).
> >
> > 2020-07-20 20:39 GMT+03:00, Pavel Tupitsyn <[hidden email]>:
> > > +1
> > >
> > > More evidence:
> > >
> >
> https://stackoverflow.com/questions/62902640/apache-ignite-cacherebalancemode-is-not-respected-by-nodes
> > >
> > > On Mon, Jul 20, 2020 at 8:26 PM Alexey Goncharuk
> > > <[hidden email]>
> > > wrote:
> > >
> > >> Igniters,
> > >>
> > >> I would like to run the idea of deprecating and probably ignoring the
> > >> NONE
> > >> rebalance mode by the community. It's in the removal list for Ignite
> 3.0
> > >> [1], but it looks like it still confuses and creates issues for users
> > >> [2].
> > >>
> > >> What about deprecating it in one of the next releases and even
> ignoring
> > >> this constant in further releases, interpreting it as ASYNC, before
> > >> Ignite
> > >> 3.0? I find it hard to believe that any Ignite user actually has
> > >> RebalanceMode.NONE set in their configuration due to its absolutely
> > >> unpredictable behavior.
> > >>
> > >> Thanks for your thoughts,
> > >> --AG
> > >>
> > >> [1]
> > >>
> > >>
> >
> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0+Wishlist
> > >> [2]
> > >>
> > >>
> >
> http://apache-ignite-developers.2346864.n4.nabble.com/About-Rebalance-Mode-SYNC-amp-NONE-td47279.html
> > >>
> > >
> >
> >
> > --
> >
> > Best regards,
> > Ivan Pavlukhin
> >
>

Ivan Pavlukhin

Re: Getting rid of NONE cache rebalance mode

Alexey,

Thank you for explanation. I feel that I miss a couple bits to
understand the picture fully. I am thinking about a case which I tend
to call a Memcached use-case. There is a cache over underlying storage
with read-through and expiration and without any rebalancing at all.
When new nodes enter they take ownership for some partitions from
already running nodes and serve client requests. Entries for not
owning anymore partitions expire according to configuration.

Actually, I have an idea. My guess is that "rebalancing" is a smarter
and better approach than waiting for expiration. Am I right?

2020-07-21 15:31 GMT+03:00, Alexey Goncharuk <[hidden email]>:

> Ivan,
>
> In my understanding this mode does not work at all even in the presence of
> ForceKeysRequest which is now supposed to fetch values from peers in case
> of a miss. In this mode we 1) move partitions to OWNING state
> unconditionally, and 2) choose an arbitrary OWNING node for force keys
> request. Therefore, after a user started two additional nodes in a cluster,
> the request may be mapped to a node which does not hold any data. We will
> do a read-through in this case, but it will result in significant load
> increase on a third-party storage right after a node started, which means
> that adding a node will increase, not decrease, the load on the database
> being cached.
> All these issues go away when (A)SYNC mode is used.
>
> Val,
> The idea makes sense to me - a user can use rebalance future to wait for
> rebalance to finish. This will simplify the configuration even further.
>
> пн, 20 июл. 2020 г. в 21:27, Valentin Kulichenko <
> [hidden email]>:
>
>> +1 for deprecating/removing NONE mode.
>>
>> Alexey, what do you think about the SYNC mode? In my experience, it does
>> not add much value as well. I would go as far as removing the
>> rebalancingMode parameter altogether (probably in 3.0).
>>
>> -Val
>>
>> On Mon, Jul 20, 2020 at 11:09 AM Ivan Pavlukhin <[hidden email]>
>> wrote:
>>
>> > Alexey, Igniters,
>> >
>> > Could you please outline motivation answering following questions?
>> > 1. Does this mode generally work correctly today?
>> > 2. Can this mode be useful at all?
>> >
>> > I can imagine that it might be useful in a transparent caching use
>> > case (if I did not misunderstand).
>> >
>> > 2020-07-20 20:39 GMT+03:00, Pavel Tupitsyn <[hidden email]>:
>> > > +1
>> > >
>> > > More evidence:
>> > >
>> >
>> https://stackoverflow.com/questions/62902640/apache-ignite-cacherebalancemode-is-not-respected-by-nodes
>> > >
>> > > On Mon, Jul 20, 2020 at 8:26 PM Alexey Goncharuk
>> > > <[hidden email]>
>> > > wrote:
>> > >
>> > >> Igniters,
>> > >>
>> > >> I would like to run the idea of deprecating and probably ignoring
>> > >> the
>> > >> NONE
>> > >> rebalance mode by the community. It's in the removal list for Ignite
>> 3.0
>> > >> [1], but it looks like it still confuses and creates issues for
>> > >> users
>> > >> [2].
>> > >>
>> > >> What about deprecating it in one of the next releases and even
>> ignoring
>> > >> this constant in further releases, interpreting it as ASYNC, before
>> > >> Ignite
>> > >> 3.0? I find it hard to believe that any Ignite user actually has
>> > >> RebalanceMode.NONE set in their configuration due to its absolutely
>> > >> unpredictable behavior.
>> > >>
>> > >> Thanks for your thoughts,
>> > >> --AG
>> > >>
>> > >> [1]
>> > >>
>> > >>
>> >
>> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0+Wishlist
>> > >> [2]
>> > >>
>> > >>
>> >
>> http://apache-ignite-developers.2346864.n4.nabble.com/About-Rebalance-Mode-SYNC-amp-NONE-td47279.html
>> > >>
>> > >
>> >
>> >
>> > --
>> >
>> > Best regards,
>> > Ivan Pavlukhin
>> >
>>
>

--

Best regards,
Ivan Pavlukhin

Alexei Scherbakov

Re: Getting rid of NONE cache rebalance mode

Ivan,
My opinion the ASYNC rebalancing is a best approach for off-loading 3-d
party store, and it provides consistency.

+1 for deprecation of NONE in the next release - ignore NONE and use ASYNC
instead
For those who require absence of rebalancing for some reason still be
possible to use rebalanceDelay=infinity.

+1 for removal of rebalanceMode in 3.0.
Note what we still require SYNC logic internally for system cache in some
places.

вт, 21 июл. 2020 г. в 15:59, Ivan Pavlukhin <[hidden email]>:

> Alexey,
>
> Thank you for explanation. I feel that I miss a couple bits to
> understand the picture fully. I am thinking about a case which I tend
> to call a Memcached use-case. There is a cache over underlying storage
> with read-through and expiration and without any rebalancing at all.
> When new nodes enter they take ownership for some partitions from
> already running nodes and serve client requests. Entries for not
> owning anymore partitions expire according to configuration.
>
> Actually, I have an idea. My guess is that "rebalancing" is a smarter
> and better approach than waiting for expiration. Am I right?
>
> 2020-07-21 15:31 GMT+03:00, Alexey Goncharuk <[hidden email]>:
> > Ivan,
> >
> > In my understanding this mode does not work at all even in the presence
> of
> > ForceKeysRequest which is now supposed to fetch values from peers in case
> > of a miss. In this mode we 1) move partitions to OWNING state
> > unconditionally, and 2) choose an arbitrary OWNING node for force keys
> > request. Therefore, after a user started two additional nodes in a
> cluster,
> > the request may be mapped to a node which does not hold any data. We will
> > do a read-through in this case, but it will result in significant load
> > increase on a third-party storage right after a node started, which means
> > that adding a node will increase, not decrease, the load on the database
> > being cached.
> > All these issues go away when (A)SYNC mode is used.
> >
> > Val,
> > The idea makes sense to me - a user can use rebalance future to wait for
> > rebalance to finish. This will simplify the configuration even further.
> >
> > пн, 20 июл. 2020 г. в 21:27, Valentin Kulichenko <
> > [hidden email]>:
> >
> >> +1 for deprecating/removing NONE mode.
> >>
> >> Alexey, what do you think about the SYNC mode? In my experience, it does
> >> not add much value as well. I would go as far as removing the
> >> rebalancingMode parameter altogether (probably in 3.0).
> >>
> >> -Val
> >>
> >> On Mon, Jul 20, 2020 at 11:09 AM Ivan Pavlukhin <[hidden email]>
> >> wrote:
> >>
> >> > Alexey, Igniters,
> >> >
> >> > Could you please outline motivation answering following questions?
> >> > 1. Does this mode generally work correctly today?
> >> > 2. Can this mode be useful at all?
> >> >
> >> > I can imagine that it might be useful in a transparent caching use
> >> > case (if I did not misunderstand).
> >> >
> >> > 2020-07-20 20:39 GMT+03:00, Pavel Tupitsyn <[hidden email]>:
> >> > > +1
> >> > >
> >> > > More evidence:
> >> > >
> >> >
> >>
> https://stackoverflow.com/questions/62902640/apache-ignite-cacherebalancemode-is-not-respected-by-nodes
> >> > >
> >> > > On Mon, Jul 20, 2020 at 8:26 PM Alexey Goncharuk
> >> > > <[hidden email]>
> >> > > wrote:
> >> > >
> >> > >> Igniters,
> >> > >>
> >> > >> I would like to run the idea of deprecating and probably ignoring
> >> > >> the
> >> > >> NONE
> >> > >> rebalance mode by the community. It's in the removal list for
> Ignite
> >> 3.0
> >> > >> [1], but it looks like it still confuses and creates issues for
> >> > >> users
> >> > >> [2].
> >> > >>
> >> > >> What about deprecating it in one of the next releases and even
> >> ignoring
> >> > >> this constant in further releases, interpreting it as ASYNC, before
> >> > >> Ignite
> >> > >> 3.0? I find it hard to believe that any Ignite user actually has
> >> > >> RebalanceMode.NONE set in their configuration due to its absolutely
> >> > >> unpredictable behavior.
> >> > >>
> >> > >> Thanks for your thoughts,
> >> > >> --AG
> >> > >>
> >> > >> [1]
> >> > >>
> >> > >>
> >> >
> >>
> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0+Wishlist
> >> > >> [2]
> >> > >>
> >> > >>
> >> >
> >>
> http://apache-ignite-developers.2346864.n4.nabble.com/About-Rebalance-Mode-SYNC-amp-NONE-td47279.html
> >> > >>
> >> > >
> >> >
> >> >
> >> > --
> >> >
> >> > Best regards,
> >> > Ivan Pavlukhin
> >> >
> >>
> >
>
>
> --
>
> Best regards,
> Ivan Pavlukhin
>

--

Best regards,
Alexei Scherbakov

Alexei Scherbakov

Re: Getting rid of NONE cache rebalance mode

As a reminder - we already have a ticket for a deprecation of
rebalanceDelay as well [1]

[1] https://issues.apache.org/jira/browse/IGNITE-12662

ср, 22 июл. 2020 г. в 09:39, Alexei Scherbakov <[hidden email]
>:

> Ivan,
> My opinion the ASYNC rebalancing is a best approach for off-loading 3-d
> party store, and it provides consistency.
>
> +1 for deprecation of NONE in the next release - ignore NONE and use ASYNC
> instead
> For those who require absence of rebalancing for some reason still be
> possible to use rebalanceDelay=infinity.
>
> +1 for removal of rebalanceMode in 3.0.
> Note what we still require SYNC logic internally for system cache in some
> places.
>
>
>
> вт, 21 июл. 2020 г. в 15:59, Ivan Pavlukhin <[hidden email]>:
>
>> Alexey,
>>
>> Thank you for explanation. I feel that I miss a couple bits to
>> understand the picture fully. I am thinking about a case which I tend
>> to call a Memcached use-case. There is a cache over underlying storage
>> with read-through and expiration and without any rebalancing at all.
>> When new nodes enter they take ownership for some partitions from
>> already running nodes and serve client requests. Entries for not
>> owning anymore partitions expire according to configuration.
>>
>> Actually, I have an idea. My guess is that "rebalancing" is a smarter
>> and better approach than waiting for expiration. Am I right?
>>
>> 2020-07-21 15:31 GMT+03:00, Alexey Goncharuk <[hidden email]
>> >:
>> > Ivan,
>> >
>> > In my understanding this mode does not work at all even in the presence
>> of
>> > ForceKeysRequest which is now supposed to fetch values from peers in
>> case
>> > of a miss. In this mode we 1) move partitions to OWNING state
>> > unconditionally, and 2) choose an arbitrary OWNING node for force keys
>> > request. Therefore, after a user started two additional nodes in a
>> cluster,
>> > the request may be mapped to a node which does not hold any data. We
>> will
>> > do a read-through in this case, but it will result in significant load
>> > increase on a third-party storage right after a node started, which
>> means
>> > that adding a node will increase, not decrease, the load on the database
>> > being cached.
>> > All these issues go away when (A)SYNC mode is used.
>> >
>> > Val,
>> > The idea makes sense to me - a user can use rebalance future to wait for
>> > rebalance to finish. This will simplify the configuration even further.
>> >
>> > пн, 20 июл. 2020 г. в 21:27, Valentin Kulichenko <
>> > [hidden email]>:
>> >
>> >> +1 for deprecating/removing NONE mode.
>> >>
>> >> Alexey, what do you think about the SYNC mode? In my experience, it
>> does
>> >> not add much value as well. I would go as far as removing the
>> >> rebalancingMode parameter altogether (probably in 3.0).
>> >>
>> >> -Val
>> >>
>> >> On Mon, Jul 20, 2020 at 11:09 AM Ivan Pavlukhin <[hidden email]>
>> >> wrote:
>> >>
>> >> > Alexey, Igniters,
>> >> >
>> >> > Could you please outline motivation answering following questions?
>> >> > 1. Does this mode generally work correctly today?
>> >> > 2. Can this mode be useful at all?
>> >> >
>> >> > I can imagine that it might be useful in a transparent caching use
>> >> > case (if I did not misunderstand).
>> >> >
>> >> > 2020-07-20 20:39 GMT+03:00, Pavel Tupitsyn <[hidden email]>:
>> >> > > +1
>> >> > >
>> >> > > More evidence:
>> >> > >
>> >> >
>> >>
>> https://stackoverflow.com/questions/62902640/apache-ignite-cacherebalancemode-is-not-respected-by-nodes
>> >> > >
>> >> > > On Mon, Jul 20, 2020 at 8:26 PM Alexey Goncharuk
>> >> > > <[hidden email]>
>> >> > > wrote:
>> >> > >
>> >> > >> Igniters,
>> >> > >>
>> >> > >> I would like to run the idea of deprecating and probably ignoring
>> >> > >> the
>> >> > >> NONE
>> >> > >> rebalance mode by the community. It's in the removal list for
>> Ignite
>> >> 3.0
>> >> > >> [1], but it looks like it still confuses and creates issues for
>> >> > >> users
>> >> > >> [2].
>> >> > >>
>> >> > >> What about deprecating it in one of the next releases and even
>> >> ignoring
>> >> > >> this constant in further releases, interpreting it as ASYNC,
>> before
>> >> > >> Ignite
>> >> > >> 3.0? I find it hard to believe that any Ignite user actually has
>> >> > >> RebalanceMode.NONE set in their configuration due to its
>> absolutely
>> >> > >> unpredictable behavior.
>> >> > >>
>> >> > >> Thanks for your thoughts,
>> >> > >> --AG
>> >> > >>
>> >> > >> [1]
>> >> > >>
>> >> > >>
>> >> >
>> >>
>> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0+Wishlist
>> >> > >> [2]
>> >> > >>
>> >> > >>
>> >> >
>> >>
>> http://apache-ignite-developers.2346864.n4.nabble.com/About-Rebalance-Mode-SYNC-amp-NONE-td47279.html
>> >> > >>
>> >> > >
>> >> >
>> >> >
>> >> > --
>> >> >
>> >> > Best regards,
>> >> > Ivan Pavlukhin
>> >> >
>> >>
>> >
>>
>>
>> --
>>
>> Best regards,
>> Ivan Pavlukhin
>>
>
>
> --
>
> Best regards,
> Alexei Scherbakov
>

--

Best regards,
Alexei Scherbakov

Alexey Goncharuk

Re: Getting rid of NONE cache rebalance mode

In reply to this post by Ivan Pavlukhin

Ivan,

Sorry for a delay in reply. Yes, I was thinking about the same use-case,
and in this particular case an unexpected load on a 3rd-party database
manifests itself. I am not sure how expiration relates to the partition
ownership - once a partition moves to a renting state, all entries are
eagerly cleaned from the memory, so there is no need for expiration.

Can you elaborate on your idea how rebalancing relates to expiration?

вт, 21 июл. 2020 г. в 15:59, Ivan Pavlukhin <[hidden email]>:

Ivan Pavlukhin

Re: Getting rid of NONE cache rebalance mode

Alexey,

Thank you for the response.

> I am not sure how expiration relates to the partition ownership - once a partition moves to a renting state, all entries are eagerly cleaned from the memory, so there is no need for expiration.

It is even better, there is nothing to do with expiration. Due to
unknown reason I thought about systems not sharing actual partition
distribution between nodes.

2020-07-28 18:19 GMT+03:00, Alexey Goncharuk <[hidden email]>:

> Ivan,
>
> Sorry for a delay in reply. Yes, I was thinking about the same use-case,
> and in this particular case an unexpected load on a 3rd-party database
> manifests itself. I am not sure how expiration relates to the partition
> ownership - once a partition moves to a renting state, all entries are
> eagerly cleaned from the memory, so there is no need for expiration.
>
> Can you elaborate on your idea how rebalancing relates to expiration?
>
> вт, 21 июл. 2020 г. в 15:59, Ivan Pavlukhin <[hidden email]>:
>
>> Alexey,
>>
>> Thank you for explanation. I feel that I miss a couple bits to
>> understand the picture fully. I am thinking about a case which I tend
>> to call a Memcached use-case. There is a cache over underlying storage
>> with read-through and expiration and without any rebalancing at all.
>> When new nodes enter they take ownership for some partitions from
>> already running nodes and serve client requests. Entries for not
>> owning anymore partitions expire according to configuration.
>>
>> Actually, I have an idea. My guess is that "rebalancing" is a smarter
>> and better approach than waiting for expiration. Am I right?
>>
>> 2020-07-21 15:31 GMT+03:00, Alexey Goncharuk
>> <[hidden email]>:
>> > Ivan,
>> >
>> > In my understanding this mode does not work at all even in the presence
>> of
>> > ForceKeysRequest which is now supposed to fetch values from peers in
>> > case
>> > of a miss. In this mode we 1) move partitions to OWNING state
>> > unconditionally, and 2) choose an arbitrary OWNING node for force keys
>> > request. Therefore, after a user started two additional nodes in a
>> cluster,
>> > the request may be mapped to a node which does not hold any data. We
>> > will
>> > do a read-through in this case, but it will result in significant load
>> > increase on a third-party storage right after a node started, which
>> > means
>> > that adding a node will increase, not decrease, the load on the
>> > database
>> > being cached.
>> > All these issues go away when (A)SYNC mode is used.
>> >
>> > Val,
>> > The idea makes sense to me - a user can use rebalance future to wait
>> > for
>> > rebalance to finish. This will simplify the configuration even further.
>> >
>> > пн, 20 июл. 2020 г. в 21:27, Valentin Kulichenko <
>> > [hidden email]>:
>> >
>> >> +1 for deprecating/removing NONE mode.
>> >>
>> >> Alexey, what do you think about the SYNC mode? In my experience, it
>> >> does
>> >> not add much value as well. I would go as far as removing the
>> >> rebalancingMode parameter altogether (probably in 3.0).
>> >>
>> >> -Val
>> >>
>> >> On Mon, Jul 20, 2020 at 11:09 AM Ivan Pavlukhin <[hidden email]>
>> >> wrote:
>> >>
>> >> > Alexey, Igniters,
>> >> >
>> >> > Could you please outline motivation answering following questions?
>> >> > 1. Does this mode generally work correctly today?
>> >> > 2. Can this mode be useful at all?
>> >> >
>> >> > I can imagine that it might be useful in a transparent caching use
>> >> > case (if I did not misunderstand).
>> >> >
>> >> > 2020-07-20 20:39 GMT+03:00, Pavel Tupitsyn <[hidden email]>:
>> >> > > +1
>> >> > >
>> >> > > More evidence:
>> >> > >
>> >> >
>> >>
>> https://stackoverflow.com/questions/62902640/apache-ignite-cacherebalancemode-is-not-respected-by-nodes
>> >> > >
>> >> > > On Mon, Jul 20, 2020 at 8:26 PM Alexey Goncharuk
>> >> > > <[hidden email]>
>> >> > > wrote:
>> >> > >
>> >> > >> Igniters,
>> >> > >>
>> >> > >> I would like to run the idea of deprecating and probably ignoring
>> >> > >> the
>> >> > >> NONE
>> >> > >> rebalance mode by the community. It's in the removal list for
>> Ignite
>> >> 3.0
>> >> > >> [1], but it looks like it still confuses and creates issues for
>> >> > >> users
>> >> > >> [2].
>> >> > >>
>> >> > >> What about deprecating it in one of the next releases and even
>> >> ignoring
>> >> > >> this constant in further releases, interpreting it as ASYNC,
>> >> > >> before
>> >> > >> Ignite
>> >> > >> 3.0? I find it hard to believe that any Ignite user actually has
>> >> > >> RebalanceMode.NONE set in their configuration due to its
>> >> > >> absolutely
>> >> > >> unpredictable behavior.
>> >> > >>
>> >> > >> Thanks for your thoughts,
>> >> > >> --AG
>> >> > >>
>> >> > >> [1]
>> >> > >>
>> >> > >>
>> >> >
>> >>
>> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0+Wishlist
>> >> > >> [2]
>> >> > >>
>> >> > >>
>> >> >
>> >>
>> http://apache-ignite-developers.2346864.n4.nabble.com/About-Rebalance-Mode-SYNC-amp-NONE-td47279.html
>> >> > >>
>> >> > >
>> >> >
>> >> >
>> >> > --
>> >> >
>> >> > Best regards,
>> >> > Ivan Pavlukhin
>> >> >
>> >>
>> >
>>
>>
>> --
>>
>> Best regards,
>> Ivan Pavlukhin
>>
>

--

Best regards,
Ivan Pavlukhin