This is related to https://github.com/grpc/grpc-java/issues/2563. The tl;dr of https://github.com/grpc/grpc-java/issues/2563 is "don't do that" which we agree with in principle but don't have an efficient way to implement.
We've had cases where our gRPC server has sent messages greater than a client was prepared to handle. (FWIW, server is java, client is go and the call is streaming in both directions.) The clients enforce a maximum receipt size but we don't have a way to cap the size sent by the server: the message is dependent on user code in a moderately complex way. Trying to send this message is an error case and we're prepared to deal with it, but we haven't found a graceful way to detect it. What happens now is that the client fails the streaming call when it receives the too-large payload and we have to reestablish the call. This is pretty disruptive for us. Given that there doesn't appear to be any method on the java side for us to cap the outbound message size, our only alternative appears to be manually serialize the protos before sending them and check the size. This is feels pretty expensive. What we'd prefer is to get an error on the sender side, at the point of send, when trying to send a message that exceeds the size. That way serialization is only done once and we can error-handle immediately, before anything goes out on the wire. Thoughts? -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/2c6c1962-ac9a-4a5f-83a7-5060c594340c%40googlegroups.com.
