Re: [grpc-io] Error with pb2 file (with python 3)

Hi, sorry for late reply. The IDE i am using is Eclipse 4.6.2 with pydev (PyDev for Eclipse 5.4.0.201611281236) When I run python 3.5 and try to import the same error occurs. eric@diot:~/src/SPT_DIOT/snooopy/src$ PYTHONPATH=. python3 Python 3.5.2 (default, Nov 17 2016, 17:05:23) [GCC 5.4.0

Re: [grpc-io] Re: gRPC A6: Retries

The only use case we can think of so far would be an alternative solution to this routing affinity and hedging interaction. We initially discussed putting the previously tried addresses in the metadata of an RPC, and then the actual load balancing service would have access to it. But as mentioned,

Re: [grpc-io] Re: gRPC A6: Retries

> To address your comments, we will be making a small change to the load balancing policy with respect to hedging RPCs. The change will support passing the local lb_policy a list of previously used addresses. The list will essentially be, "if possible, don't choose one of these addresses." For

Re: [grpc-io] gRPC A6: Retries

I think the terminology here gets confusing between initial/trailing metadata, gRPC rule names, and HTTP/2 frame types. Our retry design doc was indeed underspecified in regards to dealing with initial metadata, and will be updated. I go over all of the considerations in detail below. For

Re: [grpc-io] Re: (gRPC-java) Why are all services singletons?

Josh, this is exactly what I am talking about. Each service implementation is a singleton *from the perspective of gRPC*. You cannot have more than one service implementation instance handle requests from callers. You cannot get a fresh instance for every request. Is there a specific gRPC

[grpc-io] Re: Retry policy

Server is in Java and client is in C++ On Tue, Feb 28, 2017 at 8:49 PM, Stanley Cheung wrote: > What language are your server and client implemented in respectively? > > On Friday, February 24, 2017 at 11:46:37 AM UTC-8, > ili...@luminatewireless.com wrote: >> >> Hi

Re: [grpc-io] Re: (gRPC-java) Why are all services singletons?

I think this is referring to the fact that you bind a single server object for the life of the GRPC server. Go: https://github.com/grpc/grpc-go/blob/master/server.go#L276 Java: https://github.com/grpc/grpc-java/blob/master/ compiler/src/testLite/golden/TestService.java.txt#L167 So it's not

Re: [grpc-io] Re: Grpc Server not working: Exception: "Received RST_STREAM with error code 8".

I think that the issue was on my end. I did not realize that I need to propagate the assemblyBinding changes in the .exe.config. -- You received this message because you are subscribed to the Google Groups "grpc.io" group. To unsubscribe from this group and stop receiving emails from it, send

Re: [grpc-io] Re: Grpc Server not working: Exception: "Received RST_STREAM with error code 8".

No special processing on the server side. It seems I can fix the issue if I bind both localhost and the machine IP when starting the gRPC server. In 1.0.0 it was sufficient to use only the machine IP. I will need to do some further testing to confirm this. -- You received this message because