Yash Tibrewal
Yash Tibrewal
A drive-by comment without looking at the code in detail - I did notice that you are performing blocking I/O operations inside callbacks that are invoked from gRPC such as...
As I said earlier, I haven't looked at the code to verify that there are no correctness issues. If after those operations are done, the threads are given back to...
I'll note that the instructions in the quick start guide would not work for everyone. In some cases, we do need to tweak the instructions. I am fine with removing...
Maybe just add a quick note about the number being configurable
> Something like this could work! If the plan is to do away with the fixed test values, I'm thinking we should remove their handling from the subchannel code as...
> I can't think of a better reason to remove it. Using grpc.testing.fixed_reconnect_backoff_ms in production really shouldn't be a thing. If the functionality is impossible to remove, then we should...
Can you provide a reproduction please? Also, does it work on 1.45 with epoll1?
As a stretch, it might even be useful to bisect to a particular commit.
Inconsistent behavior of RECV_STATUS_ON_CLIENT and RECV_MESSAGE operation when a call gets cancelled
@AspirinSJL Do you have a working C++ repro that I might be able to reuse?
Inconsistent behavior of RECV_STATUS_ON_CLIENT and RECV_MESSAGE operation when a call gets cancelled
@jtattermusch Can you please verify that this issue still exists. I remember dealing with similar issues in the past and I just recalled that I have a PR - https://github.com/grpc/grpc/pull/19545...