Ready for review, any feedback is appreciated:
https://issues.apache.org/jira/browse/IGNITE-17725
On Tue, Sep 20, 2022 at 9:04 AM Pavel Tupitsyn wrote:
> Igniters, thanks for your input. I'll move on with the implementation.
>
> On Thu, Sep 15, 2022 at 6:46 PM Pavel Tupitsyn
> wrote:
>
>> Mirza
Igniters, thanks for your input. I'll move on with the implementation.
On Thu, Sep 15, 2022 at 6:46 PM Pavel Tupitsyn wrote:
> Mirza,
>
> This is a good point.
>
> I assumed that assignment change is caused by a topology change, like in
> Ignite 2.x, and this affects all tables, so one flag is e
Mirza,
This is a good point.
I assumed that assignment change is caused by a topology change, like in
Ignite 2.x, and this affects all tables, so one flag is enough.
In Ignite 3, though, assignment can change due to configuration update
(number of replicas, etc), and this affects only a single ta
Pavel, thank you for the IEP!
I've read the IEP and checked PR briefly, and it is not clear to me how a
client will determine which table's assignment it should update.
I can assume that once a client receives the flag that indicates that
assignments for some table have been changed,
it will reque
Igor,
> not clear how a server would know when assignment has changed
On the server, TableManager [1] maintains the current assignment.
I've made some changes there (see the linked POC) to subscribe to those
updates.
However, as I understand, this logic is not yet complete and will be
changed so
Pavel,
Great, this feature showed great results in Ignite 2, so It's a good idea
to implement
it in Ignite 3 as well.
The IEP itself looks good to me, except it's not clear how a server would
know when
assignment has changed.
Regardless of the Tracking Assignment Changes section, I like the firs
