weingithub
weingithub
> 进程退出的时候触发的？ 是的。
> > > 进程退出的时候触发的？ > > > > > > 是的。 > > 在 main 函数里对 node 执行 shutdown & join 保证退出干净了 node的join似乎没有保证异步必须全部结束才退出。而且node本身的生命周期就是通过引用计数控制的。所以我不知道退出干净这个要怎么保证？现有的代码不支持吗？还是是需要修改现有的Node代码，在异步任务中加个引用计数跟踪？
> > > > > 进程退出的时候触发的？ > > > > > > > > > > > > 是的。 > > > > > > > > > 在 main...
从coredump的所有线程堆栈看，没有看到main函数。所以这个是退出了吗？
> 有可能是braft的问题，OnPreVoteRPCDone 这个可能是客户端侧就报错了，那不在brpc server的控制范围内 当时的controller是有超时错误的。内容如下： error_text = "[E1008]Reached timeout=3000ms @127.0.0.1:9703" 你意思是这个错误，brpc.join无法等待吗？
> join里需要增加一个等待node在飞rpc结束的逻辑 我应该明白了，就是brpc_server内的stop和join，只能管理自身作为server的rpc请求，如果自身是作为rpc的客户端，那么回调其实现在node里面，都需要添加相应的计数，然后在join里等待是吧？
> 你说的第二个问题不会发生，这里有个隐含的前提是，投票是依据自己看到的 conf，一个没加入的节点，是不会被大家看到的 可能和我们的成员变更方式有关吧。我们是这么处理成员变更的，加入原来的组成员是1,2,3。现在准备用4替换3，因此我们会先 启动4，设置成员是1,2,4。然后向组的leader调用add_peer，这个时候，Leader的组成员就变成了1,2,3,4。然后我们再删除3。最终组的成员变为1,2,4.所以在4起来的时候，它会向1,2发送消息。如果2是落后的数据节点，这个时候，如果4学习到了比2更新的数据，那么2就会给4投票。那么4就会成为leader。同时，原来的1，2,4因为假定的2是落后的，因此1,4数据接近，又会互相投票成为leader，这个时候不是会有问题吗？
> > 因此我们会先启动4，设置成员是1,2,4 > > 你们这种不经过 leader 直接指定 conf 的做法是比较危险的，容易出现脑裂的 case; > 建议的做法是新节点起来都是空的配置，然后走配置变更的接口，可以是先加再减，也可以走 change_peers 一步到位 首先非常感谢你的回答。你的意思是，我们先启动4，然后_conf初始化为空，然后我再往leader里面添加4，之后再删除3。这样吗？我有以下疑问： 1._conf是允许成员为空的吗？ 2.如果当前节点不在_conf里面，是被允许的吗？
> 可以附上截图或者相关使用代码么 以下是截图内容：  左边是实时显示的bvar数值取消，其中高位部分是10ms+，而当前圈中的是94us，右边是使用curl定时获取的脚本里的数据。在同一时间段，该值是1毫秒、3毫秒。 不知道是否是curl的获取方式同实时显示中的时间间隔或者起始时间不同？
> 可是我通过flags里面的bvar_dump，然后调整打印间隔为1秒，获取到的内容，也和界面显示的不一样呢。