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
最近遇到一个问题,设置rpc调用超时时间比较短,假设10ms,中间某次调用超时之后,后面一系列请求连续超时(两次调用间隔非常短的情况下,即完成一次调用紧接着再次发起调用,中间没有其他任何操作)。仔细观察了tcp连接情况,以及加了一些调试信息,发现某次rpc调用超时之后(超时时间10ms),100ms之后会收到超时的那次调用的结果(在rpc_client_stream.h的on_received函数中打印了seqid)。同时查看tcp连接发现并没有创建新连接,原来的tcp连接仍然是ESTABLISHED状态。目前的策略server端在处理同一个socket上的写操作应该是按照seqid顺序进行回复的,这也就解释了为何一次超时会导致连环超时。想问下这种case怎么解决呢?多谢了 @qinzuoyan
The text was updated successfully, but these errors were encountered:
奇怪,两次rpc难道用的是同一个seqId?如果是同一个seqId就不是两次rpc而是一次rpc超时后不close又立即重试了吧,收到上一个请求的响应难道不符合预期吗?@scottzzq
Sorry, something went wrong.
No branches or pull requests
最近遇到一个问题,设置rpc调用超时时间比较短,假设10ms,中间某次调用超时之后,后面一系列请求连续超时(两次调用间隔非常短的情况下,即完成一次调用紧接着再次发起调用,中间没有其他任何操作)。仔细观察了tcp连接情况,以及加了一些调试信息,发现某次rpc调用超时之后(超时时间10ms),100ms之后会收到超时的那次调用的结果(在rpc_client_stream.h的on_received函数中打印了seqid)。同时查看tcp连接发现并没有创建新连接,原来的tcp连接仍然是ESTABLISHED状态。目前的策略server端在处理同一个socket上的写操作应该是按照seqid顺序进行回复的,这也就解释了为何一次超时会导致连环超时。想问下这种case怎么解决呢?多谢了 @qinzuoyan
The text was updated successfully, but these errors were encountered: