You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@geode.apache.org by "Dan Smith (JIRA)" <ji...@apache.org> on 2016/03/23 18:56:25 UTC
[jira] [Reopened] (GEODE-478) Message class length field overflows
if size is > 2GB
[ https://issues.apache.org/jira/browse/GEODE-478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dan Smith reopened GEODE-478:
-----------------------------
I'm reopening this issue because the test for these changes, ParallelGatewaySenderOperationsDUnitTest.testParallelGatewaySenderMessageTooLargeException, passes even if the maximum message size is not set.
We need to add a stat to track when we shrink and retry a batch due to this failure and change the test to check the stat.
> Message class length field overflows if size is > 2GB
> -----------------------------------------------------
>
> Key: GEODE-478
> URL: https://issues.apache.org/jira/browse/GEODE-478
> Project: Geode
> Issue Type: Bug
> Components: client/server
> Reporter: Barry Oglesby
> Assignee: Barry Oglesby
> Fix For: 1.0.0-incubating.M2
>
>
> 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:
> {noformat}
> [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)
> {noformat}
> 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.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)