[grpc-io] gRPC internal thread in C++

I am trying to understand how many internal threads gRPC creates in async mode. I find some timer threads, and some threads in Executor. Are there any threads? Are there any short-lived thread? Also are there any threads to receive bytes from socket and deserialize them? -- You received this

Re: [grpc-io] gRPC vs DBUS?

On Wed, Jun 16, 2021 at 12:43 PM Jason Hihn wrote: > I am working on a project that currently uses DBUS and I am contemplating > moving it to ProtoBuf/gRPC. (C++ based) Protobuf seems to have many > advantages. DBus is object-oriented; you can return data (a struct) or objects (references to

[grpc-io] gRPC vs DBUS?

I am working on a project that currently uses DBUS and I am contemplating moving it to ProtoBuf/gRPC. (C++ based) Protobuf seems to have many advantages. As a newcomer, there are a few questions I had about gRPC: 1. DBUS provides a session bus and a system bus services. gRPC provides a server

Re: [grpc-io] Java grpc client behaviour on hitting H/2 max concurrent streams

Yes, this is on purpose, and is actually expected per the HTTP/2 spec . We recognize there are situations where that is not the correct behavior and more connections should be opened, although that point may be *before* hitting

[grpc-io] Re: grpc.channel_ready_future throw inactive rpc error

It seems that the client is failing to connect to the server: "failed to connect to all addresses", Are you sure that the server is listening on that port? Try running netstat on the server to verify. Are there firewall rules getting in the way? Try using nmap from the client to verify. On

[grpc-io] Re: __call__() require one positional argument 'request'

There's not a lot of information to go on here, but your error message is pretty clear in one respect: TypeError: __call__() missing 1 required positional argument: 'request' You need to supply a request when you invoke your stub (which is presumably what you're doing in this snippet). On

[grpc-io] Re: Using async grpc streaming APIs

> Does that mean there shouldn't be any outstanding Writes / Reads when this function is called? Or just that there shouldn't be a call to "Finish" when a call to "Read" or "Write" is in progress (as in multiple threads competing with each other)? I didn't see a problem with an outstanding read

[grpc-io] Re: Use of insecure C functions/API(s)

There is no roadmap to remove them that I am aware of. As for whether these functions are handled safely everywhere, that seems like an alternate way of asking if gRPC has bugs related to this. What I CAN tell you is that the code is continuously tested, and I would imagine that if there was a

[grpc-io] Re: What is the mechanism of Completion Queue?

> However, HandleRpc() only call proceed() once,. It seems we always stay in the PROCESS state. Will it generate the memory leak? No, the same CallData object is used multiple times as a completion queue tag, allowing the state to progress. > What does it mean to have cq->next(, ) return the

[grpc-io] Questions on unary RPC and error issues

I saw your pdf on using gRPC for long lived and streaming RPC and would like to ask some questions about RpcException and other issues we're getting issuing unary RPC commands from our c# server app to our localhost c++ app. We replaced WCF with gRPC for our inter-process communication, so it's