Hi, It is ok. online meeting is fine, but we need to leave a meeting records to the community.
Before that, I noticed that the email is marked as "【可能伪造邮件 POSSIBLY SPOOFED 】". Please change some settings of your mailbox... All these will be recorded on the Internet and it is not good for searching content... (BTW, if you want to reply on this thread, please modify the subject manually) Best ----------------------------------- Xiangdong Huang School of Software, Tsinghua University 黄向东 清华大学 软件学院 程建云 <chengjian...@360.cn> 于2021年8月27日周五 下午6:37写道： > > Hi, Xiangdong > > > We are glad to join in to work together to help refactor the cluster module! > > > Do you have any idea about the form of cooperation? It's better to have some > regular online meeting or something like to help improve the productivity. > > > > Thanks! > > Jianyun Cheng > > ________________________________ > 发件人: 李思佳 <lisi...@360.cn> > 发送时间: 2021年8月27日 18:25 > 收件人: dev@iotdb.apache.org > 主题: 【可能伪造邮件 POSSIBLY SPOOFED 】答复: 【可能伪造邮件 POSSIBLY SPOOFED 】Welcome to join > working on "cluster-" branch together > > Hi, > > This is Sijia Li, I am a big data engineer of Qihoo 360. > > I'd like to participate in this work with my colleague @Jianyun Cheng. > > I hope that we can have a pleasant cooperation. > > Thanks > > -----邮件原件----- > 发件人: Xiangdong Huang <saint...@gmail.com> > 发送时间: 2021年8月27日 14:33 > 收件人: dev <dev@iotdb.apache.org> > 主题: 【可能伪造邮件 POSSIBLY SPOOFED 】Welcome to join working on "cluster-" branch > together > > 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 > > 黄向东 > 清华大学 软件学院
