Re: [grpc-io] gRPC C++ performance gap vs Go

my first thought is maybe nagle algorithm is on for one and off for the other. thats probably configurable somewhere. anyway i am purely speculating. On Thu, Aug 24, 2023 at 3:46 AM 'AlexN' via grpc.io < grpc-io@googlegroups.com> wrote: > Hi, > > When looking at the QPS benchmarks >

[grpc-io] Re: TypeError: Couldn't build proto file into descriptor pool!

hey i faces the same problem where i wanted to create a package where i can import to every microservice i want and it works, and my solution was to add parent directory mapping into the package __init__.py before the import of all the py files like the following: import sys from pathlib

[grpc-io] gRFC A71: xDS fallback

https://github.com/grpc/proposal/pull/386 details a proposal to implement support for fallback when xDS control plane is not available. Comments and suggestions are welcome. -- You received this message because you are subscribed to the Google Groups "grpc.io" group. To unsubscribe from this

[grpc-io] gRPC C++ performance gap vs Go

Hi, When looking at the QPS benchmarks (and reproducing them) the performance gap between the C++ and Go is more than x2 (Go is faster). The test scenario appears to be quite similar: Streaming secure throughput QPS (8

[grpc-io] Re: Access to ByteBuffer before Deserialize

Would like to confirm that you are asking about gRPC Java (inferring from your mention of ByteBuffer). On Thursday, August 24, 2023 at 10:53:48 AM UTC-7 Abhishek Kabra wrote: > Hi, > There is issue in protobuf where nested messages (recursion) if goes > beyond 100 depth, DeSerialization fails.

[grpc-io] Re: Access to ByteBuffer before Deserialize

Hey, I am interested in grpc client running in c++/golang code. I am currently using v1.51. I understand that grpc-java, this has been fixed in v1.56, but java is not my usecase On Thursday, August 24, 2023 at 11:53:48 PM UTC+5:30 sanjay...@google.com wrote: > Would like to confirm that you

[grpc-io] Access to ByteBuffer before Deserialize

Hi, There is issue in protobuf where nested messages (recursion) if goes beyond 100 depth, DeSerialization fails. However it can be fixed via converting serialized message into input coded stream and then setting recursion limit and then doing DeSerialization. Now same issue exists in GRPC,

Re: [grpc-io] Re: After the channel is created, it takes 1000+ms to transition from IDEL state to CONNECTING state.How can i reduce the time required to change state?

Instead of modifying and using the jre/lib logging.properties file can you try using one for your application alone as described in my previous message (use Java property java.util.logging.config.file and so on)? On Wednesday, August 23, 2023 at 7:49:39 PM UTC-7 邹会江 wrote: > 1. I modified the