You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@geode.apache.org by "Edin Zulich (JIRA)" <ji...@apache.org> on 2016/02/18 23:39:18 UTC
[jira] [Commented] (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:comment-tabpanel&focusedCommentId=15153265#comment-15153265 ]
Edin Zulich commented on GEODE-478:
-----------------------------------
Change the message transmission to throw an exception and assign to wan component to handle the new exception.
> 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
>
> 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)