Tracking Issue for maxInboundMessageSize being Experimental

[carl-mastrangelo]

No description provided.

[ejona86]

This should include both ManagedChannelBuilder.maxInboundMessageSize and CallOptions.withMaxInboundMessageSize, since the two are closely related.

[ejona86]

As mentioned in #2763:

As per googleapis/google-cloud-java#1499 , users of Pub/Sub see errors when their messages exceed 4MB, even though Pub/Sub's limit is 20 MB. Ideally we'd like to call maxInboundMessageSize to raise this maximum, but it turns out that maxInboundMessageSize is experimental.

[ejona86]

I realized that all the other languages are using "max message size" on the channel. While Netty/OkhttpChannelBuilder had/have maxMessageSize, ManagedChannelBuilder has only had maxInboundMessageSize. I don't want to flip-flop users too much and the "inbound" portion of the name is a more precise, so I think it's fair to stabilize ManagedChannelBuilder.maxInboundMessageSize(int) as-is. That puts us reasonably close to other languages' support.

I think there are arguments to have the method on CallOptions as well (other than service config), but it doesn't seem to have any real use yet. It also has some awkwardness concerning int vs Integer with getMaxOutboundMessageSize(). So it doesn't seem quite time to CallOptions.maxInboundMessageSize().

Unfortunately, ServerBuilder doesn't have any configuration option and NettyServerBuilder has maxMessageSize().

[tsl0922]

4MB is too low for our environment too, we have to set it on both server/client side manually after upgrade to 1.x version.

Unfortunately, ServerBuilder doesn't have any configuration option and NettyServerBuilder has maxMessageSize().

Do you have any plan to make maxMessageSize() part of ServerBuilder?

[ejona86]

Do you have any plan to make maxMessageSize() part of ServerBuilder?

Yes. We'd add maxInboundMessageSize() to ServerBuilder to mirror ManagedChannelBuilder. I'd do that as part of removing the experimental annotation.

[ejona86]

API discussion notes:
Server-side swaps to maxInboundMessageSize(). Trash maxMessageSize(). Then considered fine for being stable.

[xin-au]

@ejona86 @carl-mastrangelo, is there any config for maxOutBoundMessageSize in the server side? I saw there is maxOutBoundMessageSize in the MessageFrame. But seems we did not expose this config to *ServerBuilder.

[carl-mastrangelo]

@xin-au can you describe your use case? Generally the server controls how big the message it sends is. The reason it is exposed on the client is to facilitate service config.

[xin-au]

@carl-mastrangelo, I encountered an issue, for the surface, the issue is the client throws some exceptions since the size of a frame it received is larger than 4MB, it is slightly larger, like around 4.4MB.
So, it means the server side sent a msg whose size is greater than 4MB. I would like to control the server side and try to set max out bound size in the server side, but I fail to find this config in the server side.
Also, the size of Frame/MessageFrame belongs to the transportation layer, I did not touch any config about this size of frame or any config of any size. So, I think the transportation layer is transparent. And the client will not be aware of the exist of max frame size.
After reading some code in grpc-java, I realized that the default max out bound is unbound(-1). And I did not set the config manually. And even I would like to set it, but I cannot set it since it is not exposed to serverBuilder and channelBuild. Correct me if I am wrong.
And what you recommend?

[ejona86]

I would like to control the server side and try to set max out bound size in the server side, but I fail to find this config in the server side.

How does that solve the problem? Your server would still trying to send too large of a message and gRPC can't take a large message and make it smaller. What's wrong with the current behavior?

You have two options: increase the client's maximum message size or have the server send smaller messages. The client change would be configuration in the channel builder. The server change requires changing your service to make smaller messages.

[xin-au]

Thanks @ejona86 for the details!
I found where I have the misunderstanding: gRPC can't take a large message and make it smaller
My opinion was the grpc will send the protobuf data into the network in the transportation layer. In this layer, the size of records will not beyond the max size of data frame.
The correct way is the grpc will send the message based on the original size of the message and will not break them into a smaller size.
So, the transportation layer is not transparent to the application layer?
Correct me if I am wrong.

[ejona86]

@xin-au, gRPC can handle any message size, up to several GB. To protect applications from large memory usage (because a message is atomic; can't be streamed) and encourage services to avoid too-large-of-messages there is functionality to limit the maximum received message size. This limit is applied before decoding a message's bytes into a message object. We also set a default limit of 4 MiB. Anyone can increase the maximum size they are willing to receive via maxInboundMessageSize() on the channel or server builder.

gRPC does split up messages on the transport into smaller chunks.

[xin-au]

@ejona86 Thanks for the details!
Why not have a threshold of max size for sending a message in the server side? is it not good practice?
I was wondering how gRPC split up messages? I am learning the source code now. I would like to gain more knowledge about gRPC.

[ejona86]

Why not have a threshold of max size for sending a message in the server side?

Why? What is to be gained? If you wanted a smaller message, just send a smaller message.

I was wondering how gRPC split up messages?

The messages become a stream of bytes and are encoded in HTTP/2's DATA frames. This is sort of similar to using HTTP/1.1 chunked encoding. Many messages can possibly be in a single DATA frame. It's also possible only a portion of a message is in a DATA frame.

[xin-au]

@ejona86 Thanks for your answers! I lack knowledge of how gRPC split up messages. Your answers are helping me.
My situation is a little bit different; it is a little bit hard to control the size of msg I would like to send. For example, the schema of protobuf I am sending is including some collections, like map, the size of those collections is not fixed, sometimes could be large.