buffer overflow? `Maximum frame size of -2147483648 exceeded ` about nifty HOT 6 CLOSED

FYI: I fixed the problem of negative size frame by doing this:

    val frameFactory = new ThriftFrameCodecFactory(){
      override def create(maxFrameSize: Int,
        defaultProtocolFactory: TProtocolFactory): ChannelHandler = {
        // TODO(agallego): This is A HACK!
        // https://github.com/facebook/nifty/issues/144

        // import com.google.common.base.Verify.verify
        // verify(maxFrameSize > 0, s"Frame size ($maxFrameSize) is negative!")
        val twogb:Int = 1 << 30
        new DefaultThriftFrameCodec(twogb, defaultProtocolFactory)
      }
    }

from nifty.

Forgot to mention that I am also using the Binary protocol & TFramed transport.

from nifty.

I also tried the client (python) with thrift 0.9.2 and 0.9.3

from nifty.

I've also, preloaded the netty version

  "io.netty" % "netty-all" % "4.0.34.Final",

to my dependencies to make sure this happens with both libs.

my python client code looks like this

def tproto(ip, port):
    socket = TSocket.TSocket(ip, port)
    transport = TTransport.TFramedTransport(socket)
    protocol = TBinaryProtocol.TBinaryProtocol(transport)
    return (protocol, transport)

def get_sched_service_client(ip, port):
    (protocol, transport) = tproto(ip, port)
    client = MyClass.Client(protocol)
    transport.open()
    return client

from nifty.

perhaps we can use this?

ThriftServerDef serverDef = thriftServerDefBuilder.limitFrameSizeTo(Integer.MAX_VALUE).build();

from nifty.

Bug here is that we should limit max frame size to under 2GB. Maybe should even be limited to just under 1GB I think. At exactly 2GB, you have bit 31 set, which Java treats as negative i32, and anyway thrift doesn't want you to set that bit because a server that understands different incoming protocols from different clients uses it to detect unframed messages.

As for 1GB, its for a similar reason, some Thrift servers also want to leave that space (with either of top two bits set) to detect HTTP incoming messages.

So yes it is a bug, but the bug is we should not allow a large size like that. And your workaround is perfect.

from nifty.