[grpc-io] Why doesn't gRPC provide a api/method for grpc client to bind the socket to a particular interface?

[jasonlittledragon]

I want my grpc client use a particular interface ip to connect grpc 
server.  For now, the source ip address grcp client used is decided by 
kernel. 
I wander, Why doesn't gRPC provide a  api/method for grpc client to bind 
the socket to a particular interface? This is kind of a common needs.
And, is there any other way to achieve this goal? Would be nice if anyone 
can help. Thanks a lot.

-- 
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 an email 
to grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/56e7f413-032c-4dc1-8dc7-aae81bbffea3%40googlegroups.com.

[grpc-io] Is there a easy way to tell where a gRPC call failed in header?

['Juanyi Feng' via grpc.io]

Is there any easy way to tell which layer did a gRPC call fail in? (gRPC 
server layer vs application code layer)

Is there any field in the header that I can look into to easily tell? Or 
what's the common practice for it?

I think it can be solved by implementing a server interceptor and flag a 
customized metadata before it goes into the application code. But I wonder 
if there's other neater way. Thanks!

-- 
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 an email 
to grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/adb07fe1-cc97-4f8f-a9ec-45b1c89fc118%40googlegroups.com.

[grpc-io] Re: Building GRPC via Bazel without BoringSSL

['Richard Belleville' via grpc.io]

"We are currently exploring defining a fake `boringssl` local_repository 
which has a single target (`@boringssl//:ssl` which points to system 
provided openssl)"

This actually sounds ideal to me. Compare what the protobuf repo does about 
Python headers 
.
 
If you come up with a robust repository rule to pull in the system openssl, 
consider making it available as an example. I imagine it will be useful to 
many besides yourself.
On Tuesday, March 3, 2020 at 3:30:35 PM UTC-8 priy...@gmail.com wrote:

> Hello,
>
> I am trying to compile GRPC without BoringSSL. Looks like this is 
> supported via cmake. Is there a way to also support it via Bazel? My 
> current understanding is that the Bazel build unconditionally depends on 
> @boringssl//:ssl.
>
> We are using Bazel to build a custom binary that links in aws-cpp-sdk and 
> grpc. It seems like aws-cpp-sdk wants openssl while grpc seems to want 
> boringssl. We are currently exploring defining a fake `boringssl` 
> local_repository which has a single target (`@boringssl//:ssl` which points 
> to system provided openssl). Would love to know if this is likely to be a 
> fool's errand.
>
> Regards!
>
>

-- 
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 an email 
to grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/e8d97291-f292-444a-85c5-10eb94883bf4%40googlegroups.com.

[grpc-io] Building GRPC via Bazel without BoringSSL

[priyendra]

Hello,

I am trying to compile GRPC without BoringSSL. Looks like this is supported 
via cmake. Is there a way to also support it via Bazel? My current 
understanding is that the Bazel build unconditionally depends on 
@boringssl//:ssl.

We are using Bazel to build a custom binary that links in aws-cpp-sdk and 
grpc. It seems like aws-cpp-sdk wants openssl while grpc seems to want 
boringssl. We are currently exploring defining a fake `boringssl` 
local_repository which has a single target (`@boringssl//:ssl` which points 
to system provided openssl). Would love to know if this is likely to be a 
fool's errand.

Regards!

-- 
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 an email 
to grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/09c0b82b-cf81-438d-b096-d2df287a5cee%40googlegroups.com.

[grpc-io] Differences between CompletionQueue, ThreadManager, ThreadPool and how they fit together

[Prabhsimran Singh]

I'm relatively new to gRPC and wanted to understand it more deeply for a 
project we're working on that requires real-time performance (C++ 
application with multi-threading).
Mainly I want to know the guiding principle behind each of the following 
components and how they fit in together:

1. CompletionQueue
2. ThreadManager
3. ThreadPool

I also read on another thread that for sync services, gRPC uses a 
DynamicThreadPool by default. Is there any way to configure the minimum 
number of threads that it starts out with or dials down to once there is no 
load. It would also be really helpful if someone could point out what 
variables I can tune, to really optimize for maximum performance on a 
multicore machine with gRPC.

-- 
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 an email 
to grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/9a2e96ef-2938-4746-af9b-0d3277a78d55%40googlegroups.com.

[grpc-io] Suggestion: gRPC services should be "production ready" by default: with limits

[Evan Jones]

*Summary: *In my opinion: the gRPC server libraries should include a 
mechanism for limiting the number of concurrent requests and connections by 
default. This is necessary for ensuring that servers stays within memory 
limits during overload. The core libraries currently do not support this, 
which requires everyone using gRPC for production use cases to reinvent the 
wheel (see below).


   - Is this something the core gRPC team agrees with? There is a 
   discussion on grpc-java that suggests maybe it is: 
   https://github.com/grpc/grpc-java/issues/1886
   - If so, I have a very bad Go implementation I would be happy to 
   contribute.
   - Maybe we should create a "best practices" document that suggests 
   people implement limits themselves, if we are waiting for the "right" 
   implementation?


Without these limits, every gRPC server is a few hundred extra connections 
away from a cascading failure. I personally would like the core library to 
set some "reasonable" limits for both requests and connections that is not 
infinite, and allow me to configure them. This is similar to how the 
library sets a maximum message size by default. However, I can understand 
that might be controversial, and potentially a significant behaviour 
change. At the very least, the libraries should include the right pieces to 
make it easy for me to configure them, without needing to implement my own 
semaphore interceptor and listener.


*Counter-argument: This is an application policy, not a gRPC policy*

An argument against this is that the "right" settings are going to be 
different for each application, so gRPC should not set something that will 
be wrong. Additionally, some applications will want sophisticated policies, 
such as allowing a large number of "cheap" requests, but only a small 
number of "expensive" requests. Today, gRPC provides the necessary hooks to 
implement these limits yourself (e.g. I implement a version at 
https://github.com/evanj/concurrentlimit).

Personally: This is true, but gRPC should at least include a "simple" 
implementation that would cover the "basic" use case. Advanced users could 
still override the default, if necessary.



*Context*

At work, we recently had a classic cascading failure of a gRPC service 
because the service ran out of memory. We believe one of the root causes is 
that during overload, our Go gRPC server accepted an unlimited amount of 
work, causing it to exceed its memory limits and get OOM killed. In 
testing, I can easily cause the server to run out of memory either by 
sending too many concurrent requests, or by establishing a very large 
number of idle gRPC connections. To be able to stay within memory limits, 
even in overload scenarios, I need this server to limit both the number of 
connections and the number of requests.

The good news is that gRPC provides the right hooks for me to implement 
this myself (see https://github.com/evanj/concurrentlimit). However, it is 



*Related Issues*

This issue on the Java implementation has the largest relevant discussion: 
https://github.com/grpc/grpc-java/issues/1886

Searching in the gRPC closed issues finds a large number of issues that may 
have been caused by a lack of limits.

It turns out that none of the gRPC implementations in any language out of 
the box support the limits necessary for a server to survive this type of 
overload. Our service is in Go, but after a quick review, it appears to me 
the same limitations exist in the Java and C++ implementations.



*People who have solved the same problem*


Lyft uses Envoy to limit concurrent requests to their services: 
https://www.infoq.com/articles/envoy-service-mesh-cascading-failure/

Dropbox created their own service proxy with similar goals: 
https://blogs.dropbox.com/tech/2018/03/meet-bandaid-the-dropbox-service-proxy/

-- 
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 an email 
to grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/f6475ce5-1c90-4427-a2cc-d6241e76b3af%40googlegroups.com.

[grpc-io] Re: gRPC binding the socket to a particular interface or device (Something like SO_BINDTODEVICE)

[Abhi Arora]

Hello,
Any possible solution or any hack to achieve the same thing?

On Tuesday, February 25, 2020 at 11:29:45 AM UTC+5:30, Abhi Arora wrote:
>
> I have a Linux Embedded Machine with gRPC cross-compiled for it. I am 
> looking to create multiple instances of gRPC each bind to a particular 
> interface or device. Linux POSIX socket provides SO_BINDTODEVICE option but 
> I am not sure if gRPC has any application layer method or function to 
> achieve it. I tried other forums but couldn't find something useful.
>
> Is there any workaround to achieve the same thing?
>
> Please help me.
>
>
>

-- 
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 an email 
to grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/8ff9fc31-c371-42d2-a6ea-22996bb1181f%40googlegroups.com.