Consider using max possible message size for TFramedTransports

[ctubbsii]

Since we're only using the framed transport because we have to, I'm wondering if we should just always set the max message size to the maximum value possible. If we're only using this transport because we have to for the server type, and not because actually want to make use of its features, like size limitations, then it'd probably be easier if we just removed the configuration option, and always set the max size possible. At the very least, we could make it so the default value is always the max size possible, without removing the config. I think one of these options would make things a lot easier on users who are hitting this.

Originally posted by @ctubbsii in https://github.com/apache/accumulo/issues/3762#issuecomment-1739951104

[ctubbsii]

@keith-turner wrote:

Accumulo uses THsHaServer as its default thrift server and it requires this

(By "this", he's referring to TFramedTransport)

@ctubbsii wrote:

But it shouldn't be required for client sockets, right?

EDIT: Nevermind, I see it says we have to at https://github.com/apache/thrift/blob/bc9c04d8049d7d5f5cf4e63a25226c1fb8c930bf/lib/java/src/main/java/org/apache/thrift/server/TNonblockingServer.java#L37-L38

[EdColeman]

@ctubbsii - should we make this a blocker for 2.1.3?

[dlmarion]

FWIW - As this is a configurable property, and #3873 just changes the default value from 1G to Integer.toString(Integer.MAX_VALUE), this may not need to be a blocker for 2.1.3. I think it's more of a nice to have when it's ready.

[ctubbsii]

I have a completed fix for this and all the related issues, but it depends on a related fix for how isPropertySet works (or rather, doesn't work) for fixed properties, which applies to these max message properties, and affects how deprecating the properties needs to be handled. That related fix is in #4752 and needs to be merged first.