[grpc-io] Re: Internal OpenSSL initialization affecting the application

Could you describe the race condition in details? In gRPC ssl_transport_security, init_openssl() is only called when ssl transport security is needed. In your application, you are calling SSL_library_init() in a separate thread in parallel? On Wednesday, April 18, 2018 at 2:46:28 PM UTC-7,

[grpc-io] Re: Internal OpenSSL initialization affecting the application

I am using grpc-1.10.0 and it has that code. Looking at the latest master, it still has that code - https://github.com/grpc/grpc/blob/master/src/core/tsi/ssl_transport_security.cc - see the init_openssl function. The problem is not just that grpc_init initialized the OpenSSL. The problem is

Re: [grpc-io] Re: CallCredentials on "Insecure" Channels (in C-based implementatons)

Yeah - this would be using my own implementation of call credentials. I think it makes perfect sense for the credentials implementation itself to define if it's okay with an insecure channel or not. That option just doesn't seem to exist, today, for grpc-core. On Wed, Apr 18, 2018 at 5:09 PM,

Re: [grpc-io] Re: CallCredentials on "Insecure" Channels (in C-based implementatons)

Thanks much for clarification! In your use case, you will define your own call credentials, right? On Wednesday, April 18, 2018 at 2:04:10 PM UTC-7, Colin Morelli wrote: > > There seems to be a misunderstanding here. I'm not sure how Istio is not a > valid use case. You only brought up the

Re: [grpc-io] Re: Channel hooks/interceptors in C++ ?

I'm sorry I didn't realize that you were trying to do this on the server side. I don't think we have anything like that on the server side. As far as I know, we don't expose those details. What exactly are you trying to achieve? On Thursday, April 12, 2018 at 10:58:06 AM UTC-7, Robert Bielik

Re: [grpc-io] Re: CallCredentials on "Insecure" Channels (in C-based implementatons)

There seems to be a misunderstanding here. I'm not sure how Istio is not a valid use case. You only brought up the case of talking to Google APIs - which is only one use for gRPC. I am referring to developers using Istio to call other services in their own service mesh. i.e. calls between two

Re: [grpc-io] Re: CallCredentials on "Insecure" Channels (in C-based implementatons)

Hi Colin, In the Istio scenario, if an application needs to call Google APIs, my understanding is that it does not connect to local proxy, the app still connects to Google API using SSL and use call credential on top of the secure connection, envoy proxy will pass through the traffic. There

[grpc-io] Re: More granularity for errors generated by gRPC itself

Responses inline On Thursday, April 12, 2018 at 2:52:10 PM UTC-7, Ruslan Nigmatullin wrote: > > Hi, > > Is there a chance to add details to errors generated by gRPC layer itself > to distinguish different scenarios instead of forcing gRPC users to analyze > error message client-side? Parsing

[grpc-io] Re: Internal OpenSSL initialization affecting the application

Hi Arpit, grpc_init initializes OpenSSL for a short period (~2 days) and the code was later removed. Do you still the problem, if you fetch the latest master? On Monday, April 16, 2018 at 2:22:32 PM UTC-7, Arpit Baldeva wrote: > > Hi, > > I recently pinned down a sporadic race condition in my

Re: [grpc-io] Re: [objective-c] Battery usage under iOS

The disposal or recrceation of the service object does not affect the channel. If you absolutely have to do this, resetHostSettings may be used to disconnect all channels and can be added after a call is

[grpc-io] Re: [objective-c] Battery usage under iOS

Just my QA folks have noticed the battery usage "seems to be unusually high". A very subjective statement to be sure. Would you recommend, the disposal / re-creation of the service object for each invocation to keep the network only open during calls? On Wednesday, April 18, 2018 at 2:29:53

[grpc-io] Building grpcio-python without recompiling core files

I was wondering if it was reasonable to have a env variable that affected the `CORE_C_FILES` that is passed into Extension in setup.py (basically something like SKIP_COMPILING_CORE). I’d like to build grpcio python from source and link against grpc_core compiled separately. My understanding of

[grpc-io] Re: [objective-c] Battery usage under iOS

Yes. By the design of gRPC, channel to an endpoint remains open after a call and the next call reuses this channel. We would love to know how bad battery drain you are seeing. On Wednesday, April 11, 2018 at 11:17:43 AM UTC-7, Rob Cecil wrote: > > Does the GRPCProtoService keep the network open

[grpc-io] Re: More granularity for errors generated by gRPC itself

The problem with that is there is not a fine-grained set of codes that we can support. Particularly, the server application may return status codes with their own definition. Adding codes is not likely to help with the situation for gRPC since there would always be scenarios that is not

[grpc-io] Re: How to enable grpc java logs?

This is correct. Like I mentioned, you will need to turn up the log level for gRPC classes. gRPC uses java.util.Logging, so you'll need to set it via that. (There are lots of ways to do this, so I can't advise on which way is right for you.) On Thursday, April 12, 2018 at 9:18:22 PM UTC-7,