gRPC java 实现 v0.15 可能会丢失数据，它在 v1 中修复了吗？背压？
gRPC java implementation v0.15 might lost data, was it fixed in v1? Backpressure?
当我使用 gRPC 的 v0.15（java 版本）时，我遇到了一个问题，如果客户端速度很慢，那么一些数据可能会丢失。 IE。服务器发出 5 mils 记录，客户端接收大约 80%。
为了处理这种情况，我必须实现本地 'buffer' 如果我想使用 gRPC 进行微服务之间的通信，这对我来说似乎是个问题。
我想知道这个问题是否已在 v1 中修复？我记得我在 gRPC 讨论中看到过（用谷歌搜索过）相应的问题，但现在找不到了。
我假设它与背压有某种关联，我们在开箱即用的 gRPC 中有背压吗？在我的测试中，1.0.2 用 io.netty.util.internal.OutOfDirectMemoryError 打击：
我应该手动实施背压吗？
只是发送消息并不意味着客户端已收到消息。 ClientCall 和 ServerCall API 将其描述为：
No generic method for determining message receipt or providing acknowledgement is provided. Applications are expected to utilize normal payload messages for such signals, as a response naturally acknowledges its request.
我同意你的问题似乎与流量有关 control/backpressure。您应该将 StreamObserver 转换为 ServerCallStreamObserver 并使用 setOnReadyHandler() 和 isReady() 来控制内存使用。有一个 brief example in an issue comment.
当我使用 gRPC 的 v0.15（java 版本）时，我遇到了一个问题，如果客户端速度很慢，那么一些数据可能会丢失。 IE。服务器发出 5 mils 记录，客户端接收大约 80%。
为了处理这种情况，我必须实现本地 'buffer' 如果我想使用 gRPC 进行微服务之间的通信，这对我来说似乎是个问题。
我想知道这个问题是否已在 v1 中修复？我记得我在 gRPC 讨论中看到过（用谷歌搜索过）相应的问题，但现在找不到了。
我假设它与背压有某种关联，我们在开箱即用的 gRPC 中有背压吗？在我的测试中，1.0.2 用 io.netty.util.internal.OutOfDirectMemoryError 打击： 我应该手动实施背压吗？
只是发送消息并不意味着客户端已收到消息。 ClientCall 和 ServerCall API 将其描述为：
No generic method for determining message receipt or providing acknowledgement is provided. Applications are expected to utilize normal payload messages for such signals, as a response naturally acknowledges its request.
我同意你的问题似乎与流量有关 control/backpressure。您应该将 StreamObserver 转换为 ServerCallStreamObserver 并使用 setOnReadyHandler() 和 isReady() 来控制内存使用。有一个 brief example in an issue comment.