Closed vipwzw closed 5 years ago
@bysomeone 你来看一下这个问题
@bysomeone 你来看一下这个问题
好的
如题,分析一下可能的原因
初步分析是在并发的情况下,消息队列sub消息时和发送的顺序可能不一致 chain33消息队列sub过程代码
go func() {
defer func() {
client.wg.Done()
}()
for {
select {
case data, ok := <-sub.high:
if client.isEnd(data, ok) {
qlog.Info("unsub1", "topic", topic)
return
}
client.Recv() <- data
default:
select {
case data, ok := <-sub.high:
if client.isEnd(data, ok) {
qlog.Info("unsub2", "topic", topic)
return
}
client.Recv() <- data
case data, ok := <-sub.low:
if client.isEnd(data, ok) {
qlog.Info("unsub3", "topic", topic)
return
}
client.Recv() <- data
case <-client.done:
qlog.Error("unsub4", "topic", topic)
return
}
}
}
TestDelBlock中调用的两个send(删除区块命令和查询mempool size命令)分别对应以上的sub.low和sub.high两个管道,正常情况是先删除再查询,即先收到low再high,但在并发情况下,可能sub的协程可能被调度睡眠,唤醒后其实sub和high都已经就绪,但high写在更前面,会优先执行high对应逻辑,也就是查询mempool size的时候还没有执行DelBlock,固然为0
类似代码demo,https://play.golang.org/p/A6DIww95dA7
至于产生并发,是go test默认执行行为,所有包的test是并发执行的,在某种并发条件下即可触发以上情况
for i in {1..100}; do go test -run DelBlock; done > delBlock.log &
for i in {1..100}; do go test -run DelBlock; done >> delBlock.log &
...
本地启动10个并发shell,打印流程中相关日志,可以复现这种情况
如题,分析一下可能的原因