Hi, I'd like to open an online discussion at 10:30 AM (Beijing Time) for this branch development. Welcome to join if you are interested. The meeting address and meeting minutes can be found here [1]
[1] https://cwiki.apache.org/confluence/display/IOTDB/Cluster+branch+discussion Best, ----------------------------------- Xiangdong Huang School of Software, Tsinghua University 黄向东 清华大学 软件学院 Xiangdong Huang <[email protected]> 于2021年8月27日周五 下午2:32写道： > > Hi, > > I have worked on "cluster-" branch for several days, but still not finished. > As I have no much time to finish it, I'd like to ask cooperators > working on it together. > Please let me know if you want to join. > > "cluster-" branch is not for fixing any bug in the cluster module, > but just for refactoring the codes to make the structure similar to > the server module. > > Some ideas in the branch: > > 1. split Thrift RPC service and RPC implementation. > In the server module, we have extracted a class called ThriftService, > which is responsible for starting a RPC service. We just need to > ingest a RPC implementation to it. > However, in the cluster module, some RPC classes mixed them, which > causes code duplication, code inconsistencies, and hard to understand. > > 2. weaken the role of MetaGroupMember. metaGroupMember is just an > engine for serving meta raft group, which should not control the whole > server too deep. So, many fields (like coordinator, etc.) are > extracted to ClusterIoTDB (renamed from ClusterMain), and ClusterIoTDB > is responsible for creating them. MetaGroupMember only can modify > these fields, rather than creating them. > > That is, the lifecycle of these fields belongs to ClusterIoTDB, rather > than MetaGroupMember. > > BTW, MetaGroupMember will be renamed to MetaGroupEngine. > > 3. Similar with the relationship between StorageEngine and > StorageProcessor in the server module, DataGroupMember can be > considered as StorageProcessor, and we need a DataGroupEngine to > control them. > > 4. I am considering how to refactor the ClientPool. there are too many > in the codes. But I have no clear idea now. > > The 2nd and 3rd refactors will lead to many unexpected issues as I am > not also very familiar with the codes. So, I have to check all UT and > ITs one by one. > > I think after the refactoring, developers who know the server module > will be easy to understand the codes in the cluster module. > > And, once the ClusterIoTDB dominates the module, it will be clear to > modify the startup process like using ID to replace Node. > > Best, > ----------------------------------- > Xiangdong Huang > School of Software, Tsinghua University > > 黄向东 > 清华大学 软件学院
