Need non-experimental way to raise maxInboundMessageSize

[garrettjonesgoogle]

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. I don't see an open issue for making it non-experimental - when will this be done?

[carl-mastrangelo]

@garrettjonesgoogle The issue is that it isn't clear if this is the right way for controlling the size. Stubs can control the message size, but so can the Channel. Should there be two ways of doing the same thing? It isn't clear where such a thing should live, and which should override which.

[garrettjonesgoogle]

I didn't realize this could be controlled through the stub. It seems like the channel would be the most appropriate place to control it.

One thing to consider is that the clients generated by https://github.com/googleapis/toolkit (and checked into https://github.com/GoogleCloudPlatform/google-cloud-java ) don't use stubs at all; they sidestep them. Thus, the ManagedChannel is the only thing in use. (That's why I didn't realize that stubs had that functionality.)

As for grpc being faced with a difficult tradeoff, I think that should be internal to grpc to sort out. The more important thing is that as it stands now, it's not possible to bump up the max size in a non-experimental way.

[carl-mastrangelo]

Oh yeah, in case not obvious, Stubs are just a lightweight wrapper around a ClientCall / ServerCall. Even if GCP doesn't use stubs, it definitely does use Calls. The API exists there too, so there is still a quasi unnecessary dichotomy.

[garrettjonesgoogle]

So how are you (grpc) going to decide?

[carl-mastrangelo]

Well, we aren't. I suppose whoever uses which API more will ultimately decide. It absolutely has to be present for implementing Service Config, but so far people tend to only want to set on on a per Channel basis. Both are important use cases, but having both complicates the API. It isn't clear what to do, and after discussing it at length, we didn't come to a conclusion.

If you really want a stable way, you can just use a custom Marshaller that checks the size of the stream as it decodes. When we do decide on a stable API, you can get rid of it.

[ejona86]

I expanded the scope of #2563 to include both APIs.