[GEODE-478] Message class length field overflows if size is > 2GB

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Fix Version/s: 1.0.0-incubating.M2
• Component/s: client/server, docs
• Assignee: Barrett Oglesby
• Reporter: Barrett Oglesby
• Created: 22/Oct/15 23:49
• Updated: 12/Apr/16 05:59
• Resolved: 28/Mar/16 17:39

Description

This bug is described in the context of a GatewaySender batch, but I think it could also happen with a client putAll.

If the batch size is sufficiently large, and the data size as well, it is possible that we attempt to send a message greater than 2GB, which blows up the receiver with an exception like this one:

[warning 2015/10/07 21:06:29.213 UTC gemfire-data-node-cer-lx-gfirep03-49002 <ServerConnection on port 1543 Thread 2> tid=0xc3af9] Server connection from [identity(10.92.5.233(gemfire-data-node-ldc-lx-gfirep08-49002:23053)<v2>:51883,connection=13; port=18172]: Unexpected IOException: 
java.io.IOException: Part length ( -2,000,248,199 ) and number of parts ( 18,001 ) inconsistent
at com.gemstone.gemfire.internal.cache.tier.sockets.Message.readPayloadFields(Message.java:793)
at com.gemstone.gemfire.internal.cache.tier.sockets.Message.readHeaderAndPayload(Message.java:742)
at com.gemstone.gemfire.internal.cache.tier.sockets.Message.read(Message.java:587)
at com.gemstone.gemfire.internal.cache.tier.sockets.Message.recv(Message.java:1087)
at com.gemstone.gemfire.internal.cache.tier.sockets.Message.recv(Message.java:1101)
at com.gemstone.gemfire.internal.cache.tier.sockets.BaseCommand.readRequest(BaseCommand.java:996)
at com.gemstone.gemfire.internal.cache.tier.sockets.ServerConnection.doNormalMsg(ServerConnection.java:770)
at com.gemstone.gemfire.internal.cache.tier.sockets.ServerConnection.doOneMessage(ServerConnection.java:952)
at com.gemstone.gemfire.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1206)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at com.gemstone.gemfire.internal.cache.tier.sockets.AcceptorImpl$1$1.run(AcceptorImpl.java:532)
at java.lang.Thread.run(Thread.java:744)

Nothing on the sender side keeps track of the total size of the message that will be sent. We need to send earlier than satisfying the batch size if the buffer gets too large. I would suggest 1GB as being the largest we should allow.