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 <ptupit...@apache.org> wrote: > Igniters, thanks for your input. I'll move on with the implementation. > > On Thu, Sep 15, 2022 at 6:46 PM Pavel Tupitsyn <ptupit...@apache.org> > 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 enough. >> In Ignite 3, though, assignment can change due to configuration update >> (number of replicas, etc), and this affects only a single table. >> >> We could somehow include the list of affected table ids with the flag. >> But I'm not sure we should do that. Configuration change seems to be a >> rare scenario. >> >> On Thu, Sep 15, 2022 at 6:26 PM Mirza Aliev <alievmi...@gmail.com> wrote: >> >>> 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 request assignments for all tables that are relevant to that >>> client >>> as long as we cannot say which table's assignments were changed. >>> Am I right in my assumption? If yes, it seems to me kinda inefficient to >>> check assignments for all tables. WDYT? >>> >>> >>> чт, 15 сент. 2022 г. в 11:07, Pavel Tupitsyn <ptupit...@apache.org>: >>> >>> > 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 soon. >>> > In any case, the server should maintain up-to-date assignment one way >>> or >>> > another, because server-side API needs to route requests as well. >>> > >>> > [1] >>> > >>> > >>> https://github.com/apache/ignite-3/pull/1080/files#diff-8539b597e51096e7007250e746e696d4e16351d09c3756b4989a1c331f788ead >>> > >>> > On Thu, Sep 15, 2022 at 10:29 AM Igor Sapego <isap...@apache.org> >>> wrote: >>> > >>> > > 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 >>> first >>> > > approach >>> > > the best. Yeah, idle clients do not get updates, but why would idle >>> > clients >>> > > need >>> > > assignment update anyway if they are idle? >>> > > >>> > > Best Regards, >>> > > Igor >>> > > >>> > > >>> > > On Thu, Sep 15, 2022 at 11:21 AM Pavel Tupitsyn < >>> ptupit...@apache.org> >>> > > wrote: >>> > > >>> > > > Igniters, >>> > > > >>> > > > Please review the IEP for client partition awareness in Ignite 3 >>> and >>> > let >>> > > me >>> > > > know what you think. >>> > > > >>> > > > [1] >>> > > > >>> > > > >>> > > >>> > >>> https://cwiki.apache.org/confluence/display/IGNITE/IEP-95+Client+Partition+Awareness >>> > > > [2] https://github.com/apache/ignite-3/pull/1080 >>> > > > >>> > > >>> > >>> >>
