apache
brpc故障恢复bug
注入网络重启故障 network restart，brpc channel发送rpc request一直超时 日志一直打印：[E112]Not connected to xxxx yet
对应代码位于：Controller::IssueRPC
brpc版本：0.9.7
bvar看channel是broken的，这样导致brpc一直无法自动恢复。有点像是socket管理的bug，broken的channel没用调用connect重连
请问“网络重启故障”具体是指什么呢？是如何注入的？我们也遇到了这个问题，client一直返回E112，直到重启才恢复，持续时间最长的client大约是40分钟。
请问“网络重启故障”具体是指什么呢？是如何注入的？我们也遇到了这个问题，client一直返回E112，直到重启才恢复，持续时间最长的client大约是40分钟。
就是执行 service network restart，复现的概率比较低，但是一旦出现了，只有重启进程才能恢复，看代码应该是Socket管理的bug，那个地方很多原子操作，非常复杂
这个问题对目前的业务影响很大，比较头疼。我想到的办法是： 1.放弃使用brpc，改用grpc，但是grpc没brpc好，c++的grpc太臃肿了 2.改源码，把Socket类改写掉，去掉那一堆复杂的原子计数，用最简单的方式实现 3.应用层规避，brpc持续出现这个错误码，进程就自杀（把channel delete掉，重连，不知道是否有效果）
这个问题对目前的业务影响很大，比较头疼。我想到的办法是： 1.放弃使用brpc，改用grpc，但是grpc没brpc好，c++的grpc太臃肿了 2.改源码，把Socket类改写掉，去掉那一堆复杂的原子计数，用最简单的方式实现 3.应用层规避，brpc持续出现这个错误码，进程就自杀（把channel delete掉，重连，不知道是否有效果）
问下现在连接类型是什么？短链接、长连接or连接池
这个问题对目前的业务影响很大，比较头疼。我想到的办法是： 1.放弃使用brpc，改用grpc，但是grpc没brpc好，c++的grpc太臃肿了 2.改源码，把Socket类改写掉，去掉那一堆复杂的原子计数，用最简单的方式实现 3.应用层规避，brpc持续出现这个错误码，进程就自杀（把channel delete掉，重连，不知道是否有效果）
第3点，应用层规避，这点应该解决不了问题，我们这边是每次都重新创建一个新的channel，但还是出现了这样的问题。
第3点，应用层规避，这点应该解决不了问题，我们这边是每次都重新创建一个新的channel，但还是出现了这样的问题。
试试重建channel的时候，设置不同的ChannelOptions::connection_group
这个问题对目前的业务影响很大，比较头疼。我想到的办法是： 1.放弃使用brpc，改用grpc，但是grpc没brpc好，c++的grpc太臃肿了 2.改源码，把Socket类改写掉，去掉那一堆复杂的原子计数，用最简单的方式实现 3.应用层规避，brpc持续出现这个错误码，进程就自杀（把channel delete掉，重连，不知道是否有效果）
问下现在连接类型是什么？短链接、长连接or连接池
是长链接
第3点，应用层规避，这点应该解决不了问题，我们这边是每次都重新创建一个新的channel，但还是出现了这样的问题。
试试重建channel的时候，设置不同的ChannelOptions::connection_group
这个方法有效，我用了后，没有再出了
我升级到了brpc1.4版本，依然没有解决这个问题，不断注入网络故障：ifconfig down/up bond的一个口，又复现了
请问你们网络故障注入的具体流程是怎样的，每次网络注入故障多久后恢复？
我升级到了brpc1.4版本，依然没有解决这个问题，不断注入网络故障：ifconfig down/up bond的一个口，又复现了
请问你们网络故障注入的具体流程是怎样的，每次网络注入故障多久后恢复？
我们是bond4组网，ifconfig down/up bond的其中一个网口，注入故障10s内随机，一直循环10几个小时，最后恢复
我升级到了brpc1.4版本，依然没有解决这个问题，不断注入网络故障：ifconfig down/up bond的一个口，又复现了
请问你们网络故障注入的具体流程是怎样的，每次网络注入故障多久后恢复？
我们是bond4组网，ifconfig down/up bond的其中一个网口，注入故障10s内随机，一直循环10几个小时，最后恢复
请问在你们的环境中，大概多久能够复现呢？
我升级到了brpc1.4版本，依然没有解决这个问题，不断注入网络故障：ifconfig down/up bond的一个口，又复现了
请问你们网络故障注入的具体流程是怎样的，每次网络注入故障多久后恢复？
我们是bond4组网，ifconfig down/up bond的其中一个网口，注入故障10s内随机，一直循环10几个小时，最后恢复
请问在你们的环境中，大概多久能够复现呢？
一般来说，这样的故障跑一个晚上，第二天早上看，brpc基本会出问题。最快的时候见过，1-2个小时就出了。 复现的时候还见过除了E112以外的错误，E1008，一直返回超时，抓包看，没有包发到server端，bvar看connection是残缺的，2天都没自动恢复，所以我猜也是处于假死状态
我升级到了brpc1.4版本，依然没有解决这个问题，不断注入网络故障：ifconfig down/up bond的一个口，又复现了
请问你们网络故障注入的具体流程是怎样的，每次网络注入故障多久后恢复？
我们是bond4组网，ifconfig down/up bond的其中一个网口，注入故障10s内随机，一直循环10几个小时，最后恢复
请问在你们的环境中，大概多久能够复现呢？
一般来说，这样的故障跑一个晚上，第二天早上看，brpc基本会出问题。最快的时候见过，1-2个小时就出了。 复现的时候还见过除了E112以外的错误，E1008，一直返回超时，抓包看，没有包发到server端，bvar看connection是残缺的，2天都没自动恢复，所以我猜也是处于假死状态
请问你们的环境中，ifconfig up bond之后立即就进行下一轮的ifconfig down bond了吗？还是等待了一段时间呢？如果等待，等了多久呢？
我升级到了brpc1.4版本，依然没有解决这个问题，不断注入网络故障：ifconfig down/up bond的一个口，又复现了
请问你们网络故障注入的具体流程是怎样的，每次网络注入故障多久后恢复？
我们是bond4组网，ifconfig down/up bond的其中一个网口，注入故障10s内随机，一直循环10几个小时，最后恢复
请问在你们的环境中，大概多久能够复现呢？
一般来说，这样的故障跑一个晚上，第二天早上看，brpc基本会出问题。最快的时候见过，1-2个小时就出了。 复现的时候还见过除了E112以外的错误，E1008，一直返回超时，抓包看，没有包发到server端，bvar看connection是残缺的，2天都没自动恢复，所以我猜也是处于假死状态
请问你们的环境中，ifconfig up bond之后立即就进行下一轮的ifconfig down bond了吗？还是等待了一段时间呢？如果等待，等了多久呢？
这样表达，应该比较准确了： while (1) { ifdown bond sleep (rand(1, 99)) ifup bond sleep(rand(1, 9)) } 这个方式只是复现的概率比较高，别的network restart，随机搞，也复现过
第3点，应用层规避，这点应该解决不了问题，我们这边是每次都重新创建一个新的channel，但还是出现了这样的问题。
试试重建channel的时候，设置不同的ChannelOptions::connection_group
这个方法有效，我用了后，没有再出了
这个是失败的时候，是将connection_group随便设置一个值吗
第3点，应用层规避，这点应该解决不了问题，我们这边是每次都重新创建一个新的channel，但还是出现了这样的问题。
试试重建channel的时候，设置不同的ChannelOptions::connection_group
这个方法有效，我用了后，没有再出了
这个是失败的时候，是将connection_group随便设置一个值吗
设置这个值的目的是让channel使用新的socket去连接server端，connection_group会参与SocketMap的key计算，只要保证每次重连的时候connection_group都设置一个不同的值就行，这样key就变了，新的channel就使用新的socket了
第3点，应用层规避，这点应该解决不了问题，我们这边是每次都重新创建一个新的channel，但还是出现了这样的问题。
试试重建channel的时候，设置不同的ChannelOptions::connection_group
这个方法有效，我用了后，没有再出了
这个是失败的时候，是将connection_group随便设置一个值吗
设置这个值的目的是让channel使用新的socket去连接server端，connection_group会参与SocketMap的key计算，只要保证每次重连的时候connection_group都设置一个不同的值就行，这样key就变了，新的channel就使用新的socket了
嗯，一般程序启动后，channel->Init后，就会一直使用了，不会修改了。如果出错的话，channel能否知道。 还是只能通过rpc错误码来修改呢
第3点，应用层规避，这点应该解决不了问题，我们这边是每次都重新创建一个新的channel，但还是出现了这样的问题。
试试重建channel的时候，设置不同的ChannelOptions::connection_group
这个方法有效，我用了后，没有再出了
这个是失败的时候，是将connection_group随便设置一个值吗
设置这个值的目的是让channel使用新的socket去连接server端，connection_group会参与SocketMap的key计算，只要保证每次重连的时候connection_group都设置一个不同的值就行，这样key就变了，新的channel就使用新的socket了
嗯，一般程序启动后，channel->Init后，就会一直使用了，不会修改了。如果出错的话，channel能否知道。 还是只能通过rpc错误码来修改呢
我用的是rpc错误码，只要rpc出错3次，不管什么错误码，我就把channel delete掉，重新设置 connection_group，重新channel->Init 这里有个要注意的地方就是channel->Init不是线程安全的，我加了锁
第3点，应用层规避，这点应该解决不了问题，我们这边是每次都重新创建一个新的channel，但还是出现了这样的问题。
试试重建channel的时候，设置不同的ChannelOptions::connection_group
这个方法有效，我用了后，没有再出了
这个是失败的时候，是将connection_group随便设置一个值吗
设置这个值的目的是让channel使用新的socket去连接server端，connection_group会参与SocketMap的key计算，只要保证每次重连的时候connection_group都设置一个不同的值就行，这样key就变了，新的channel就使用新的socket了
嗯，一般程序启动后，channel->Init后，就会一直使用了，不会修改了。如果出错的话，channel能否知道。 还是只能通过rpc错误码来修改呢
我用的是rpc错误码，只要rpc出错3次，不管什么错误码，我就把channel delete掉，重新设置 connection_group，重新channel->Init 这里有个要注意的地方就是channel->Init不是线程安全的，我加了锁
明白了，谢谢
这个问题最终解决了吗？遇到问题修改connection_group不是最终方案吧。
没有解决，设置connection_group后1年，又出现了