William, Yaolong, Thanks for starting the discussion. The idea of concurrent-mode sounds good to me. Indeed, let's call it add-mode since it is for adding a member.
Regards, Tsz-Wo On Tue, Jun 14, 2022 at 1:00 AM William Song <[email protected]> wrote: > Hi Yaolong, > > Concurrent mode seems great, I’ve created a Jira at > https://issues.apache.org/jira/browse/RATIS-1592 < > https://issues.apache.org/jira/browse/RATIS-1592> > > Best Wishes > William Song > > > 2022年6月14日 12:56，yaolongliu <[email protected]> 写道： > > > > Hi William: > > > > I have an idea whether it is possible to add a mode to setConfiguration, > called concurrent mode, in this mode: we only add members to the new member > list that are temporarily not in the current list, and do not delete > existing members. Consider the following scenarios: > > Suppose there are now three members A B C in the cluster, > > > > D called setConfiguration(newPeers=[A, B, C, D]) > > E called setConfiguration(newPeers=[A, B, C, E]) > > In the current code logic, the cluster members will end up being A, B, > C, D or A, B, C, E, but what we want is A, B, C, D, E > > > > In concurrent mode: > > We assume that E's request is executed successfully first, and the > current members of the cluster are A, B, C, E, and then start to execute > D's request. At this time, we find that D is not in the list, so we just > add D instead of deleting E. The clusters eventually become A, B, C, D, E > > In addition, we can hand over to the user whether to use concurrent mode > to execute setConfiguration. Also, could you create a jira to discuss this, > thanks! > > > > Best Wishes, > > Yaolong Liu > > > >> 2022年6月14日 上午10:57，William Song <[email protected]> 写道： > >> > >> Hi all, > >> > >> We met problems on concurrent setConfiguration scenario and we want to > seek for your help. > >> > >> Consider the scenario where group contains A as leader, and B/C both > want to join the group. Since B and C are not aware of each other during > start up, they send request as follows: > >> 1. B called setConfiguration(newPeers=[A,B]) > >> 2. C called setConfiguration(newPeers=[A,C]) > >> The two requests arrive A concurrently, both successfully executed, > which lead to only B or C can participate in the final configuration, not B > and C as expected. > >> > >> How are we supposed to handle this scenario? > >> > >> Best wishes, > >> William Song > >> > >> > >
