We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
在使用异步进行上链时,当上链数据特别大的情况下,会出现运行卡住的情况。 经过排查,发现是channal.go文件中,在进行rpc请求时,会把uuid写入map池,然后监听Notify通道。当processMessage函数收到相应uuid的回馈信息后,会向通道进行传空的结构体,然后通道收到消息后就不会堵塞。但是实际运行中发现,程序有可能会死在那个notify通道那里,阻塞了。排查原因发现,将uuid写入map池的这个过程放在了发送数据之后,这就导致了有可能我这边发送完之后,节点的返回信息先于我打包进map池子,进而发生了永久性堵塞,这个堵塞是没有办法解决的。也就是说,从发请求到接收到反馈信息的过程,是快于我去执行下图中右边那个图462-464行的过程的。 下图就是我调整了代码位置后,程序运行正常
The text was updated successfully, but these errors were encountered:
欢迎你提个PR到master分支,先记录在map中然后再发送,发送失败的时候从map中删除 @dyy8888
Sorry, something went wrong.
已提交
#203
No branches or pull requests
在使用异步进行上链时,当上链数据特别大的情况下,会出现运行卡住的情况。
经过排查,发现是channal.go文件中,在进行rpc请求时,会把uuid写入map池,然后监听Notify通道。当processMessage函数收到相应uuid的回馈信息后,会向通道进行传空的结构体,然后通道收到消息后就不会堵塞。但是实际运行中发现,程序有可能会死在那个notify通道那里,阻塞了。排查原因发现,将uuid写入map池的这个过程放在了发送数据之后,这就导致了有可能我这边发送完之后,节点的返回信息先于我打包进map池子,进而发生了永久性堵塞,这个堵塞是没有办法解决的。也就是说,从发请求到接收到反馈信息的过程,是快于我去执行下图中右边那个图462-464行的过程的。
下图就是我调整了代码位置后,程序运行正常
The text was updated successfully, but these errors were encountered: