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 > >
