CHchrislusf·Aug 18, 2026
Actually, I managed to reproduce this. It was caused by upstream grpc connection pool (https://github.com/grpc/grpc-go/issues/9330). Fixing it now.
In On AI regulation and messaginggrpc
grpc-go
Go2016–2026
grpc / grpc-go
grpc-go
The Go language implementation of gRPC. HTTP/2 based RPC
26Distinct people
28Mentions
0Explicit recommenders
23.1KGitHub stars
What to know before exploring
What it is
The Go language implementation of gRPC. HTTP/2 based RPC
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- grpc/grpc · linked in 2 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year28 dated mentions
Observed mentions: 2016-02-12 16:43:29 UTC to 2026-08-18 22:31:21 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 5 | 0 | 5 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 4 | 0 | 4 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 3 | 1 | 2 |
What Hacker News says
28 sourcesUnbounded connection churn issue in gRPC-go
3 points · Open discussionMy gRPC point is that it already gives you a language for describing interfaces and support for generating client types from it, and already abstracts the connection management[1]. If OBI just generated a gRPC ClientConn implementation to map the Invoke calls to eg REST paths, it’d inherit the large existing gRPC client ecosystem. That ClientConn interface can already technically capture what OBI calls binding executors. People don’t do this though because it’s not worth it.
[1]: https://github.com/grpc/grpc-go/blob/06fc26a196350499dd0cf2d...
In One interface, every protocolI can give an n=1 anecdote here: the dns resolver used to have hard-coded caching which meant that it would be unresponsive to pod updates, and cause mini 30s outages.
The code in question was: https://github.com/grpc/grpc-go/blob/b597a8e1d0ce3f63ef8a7b6...
That meant that deploying a service which drained in less than 30s would have a little mini-outage for that service until the in-process DNS cache expired, with of course no way to configure it.
Kuberesolver streams updates, and thus lets clients talk to new pods almost immediately.
I think things are a little better now, but based on my reading of https://github.com/grpc/grpc/issues/12295, it looks like the dns resolver still might not resolve new pod names quickly in some cases.
In Intelligent Kubernetes Load Balancing at DatabricksThat seems to work, thank you!
Now latency is just RTT + server time + payloadsize/bandwidth, not multiple times RTT: https://github.com/grpc/grpc-go/issues/8436#issuecomment-311...
I was not aware of this setting, it's pretty unfortunate this is a system-level setting that can't be overridden on application layer, and the idle timeout can't be changed either. Will have to figure out how to safely make this change on the k8s service this is affecting...
In The Surprising gRPC Client Bottleneck in Low-Latency NetworksSomewhat related, I'm running into a gRPC latency issue in https://github.com/grpc/grpc-go/issues/8436
If request payload exceeds certain size the response latency goes from network RTT to double that, or triple.
Definitely something wrong with either TCP or HTTP/2 windowing as it doesn't send the full request without getting ACK from server first. But none of the gRPC windowing config options nor linux tcp_wmem/rmem settings work. Sending one byte request every few hundred milliseconds fixes it by keeping the gRPC channel / TCP connection active. Nagle / slow start is disabled.
In The Surprising gRPC Client Bottleneck in Low-Latency NetworksThere's not much of a Remote Procedure Call built into the protocol.
It's like GraphQL with resolvers.
They have you imagine it's a procedure, but you can ignore that. You can have multiple responses, but they don't keep the analogy going for that. They don't suggest generators. https://grpc.io/docs/what-is-grpc/core-concepts/
Here's the golang gRPC Hello World where the interface clearly comes first rather than the procedure. HelloRequest / HelloReply is analogous to HTTP (except with HTTP it's officially a response and you usually see Response in the API but not always [1]). https://github.com/grpc/grpc-go/blob/master/examples/hellowo...
To me, this is a good thing. Good protocol, annoying name.
1: https://fastify.dev/docs/latest/Reference/Reply/
In xAI Grok API BetaThe reflection service is open-sourced (at least for some sdks):
* https://github.com/grpc/grpc-go/blob/master/Documentation/se...
* https://chromium.googlesource.com/external/github.com/grpc/g...
You must explicitly enable it in code and many people… well just dont
In Reverse Engineering Protobuf Definitions from Compiled BinariesIf you read the first comment, you’ll see the API was documented as being experimental.
https://github.com/grpc/grpc-go/issues/3798#issuecomment-670...
In Curl 8.0.1I'd rather deal with that than the team at Google who maintains the grpc Go library who are more than fine breaking the public API in minor changes.
https://github.com/grpc/grpc-go/issues/3798
In Curl 8.0.1Found the root cause from https://github.com/grpc/grpc-go/commit/383b1143 (original issue: https://github.com/grpc/grpc-go/issues/75):
// Note that ServeHTTP uses Go's HTTP/2 server implementation which is
// totally separate from grpc-go's HTTP/2 server. Performance and
// features may vary between the two paths.
The lightstep collector serves both gRPC and HTTP traffic on the same port, using the ServeHTTP method from the comment above. Unfortunately, Go's HTTP/2 server doesn't have the improvements mentioned in https://grpc.io/blog/grpc-go-perf-improvements/#reducing-flu.... The frequent flushes mean it can suffer from high latency with Nagle enabled, or from high packet overhead with Nagle disabled.
tl;dr: blame bradfitz instead :)
In Golang disables Nagle's Algorithm by defaultI've said this often specifically in the context of golang, but while you're right that retries and similar are a common case, they are fairly similar to the 'expected' error case in the article, and can almost always be handled at precisely the place where you raise the error.
In python this is
@retry.retry(exceptions=[RpcException], tries=5, backoff=2, jitter=1)
def my_external_rpc_call(...):
....
And RpcException will only be raised beyond this if the backend is unreachable for ~30 seconds.
Similarly, rpc services can abstract over this entirely, grpc (and presumably others) allow you to configure the retry policy per rpc service or method, and have it reflected everywhere that is used, without writing wrappers[0].
Which really all is to say, once you have solid libraries that handle retries of operations that are know
Read the rest
n to be error prone (file IO, network IO, things that could lock/block, etc.) you pretty quickly get into "any error implies we're totally boned".
[0]: https://github.com/grpc/grpc-go/blob/f601dfac73c9/examples/f...
Caddy is capable of handling bidirectional gRPC streams! I have just tested it, and it works just fine. Caddy will immediately flush writes when upstream is `h2` or `h2c`[0] instead of having to wait until reading from socket is complete
I used this Caddyfile to proxy to the route_guide example (https://github.com/grpc/grpc-go/tree/master/examples/route_g...):
```
localhost {
reverse_proxy h2c://localhost:50051
}
```
It works like a charm.
[0] https://github.com/caddyserver/caddy/blob/e4ce40f8ff04240540...
In Nginx Modern Reference ArchitecturesI feel like xDS is a relatively new addition to gRPC. I think there is another parallel implementation inside gRPC of external load balancing, which may convey server load information back to the gRPC client.
I looked up the current state of the xDS code, and there's a lot more of it than I remember. The EndpointDiscoveryService based gRPC balancer is here: https://github.com/grpc/grpc-go/blob/master/xds/internal/bal.... It appears to balance similarly to Envoy; locality-aware with priorities.
(That doesn't surprise me because I don't remember any field in the ClusterLoadAssignement proto that sends load information back to the client. Health, yes; load, no. But I could easily not remember it being there because it hasn't been something I've tried to implement.)
But yeah, the way to look at endpoint discovery is like DNS. DNS can re
Read the rest
turn multiple hosts, and clients will spread the load by picking one at random (sometimes, if you're lucky). EDS is similar to this, but is a streaming RPC protocol instead of connectionless UDP, so it's theoretically easier to operate and monitor.
The other xDSes do more things -- CDS lets you discover services (that EDS then gives you endpoints for). RDS lets you make routing decisions (send 10% of traffic to the canary backend). SDS distributes TLS keys (and other secrets). ADS aggregates all of these xDSes into one RPC, so that you can atomically change the various config versions (whereas requesting each type of stream would only be "eventually consistent"; doing it atomically is good where route table changes add new clusters, the client is guaranteed to see the new cluster at the same time the route to that cluster becomes available).
It is all somewhat complicated but very well designed. This reminds me that I want to look more deeply into gRPC's support of xDS and add some integration tests between gRPC and ekglue.
Showing the 15 most recent of 28 sources. Enable JavaScript to search and browse every indexed mention.