geode-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Barry Oglesby (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (GEODE-478) Message class length field overflows if size is > 2GB
Date Tue, 27 Oct 2015 18:19:27 GMT

     [ https://issues.apache.org/jira/browse/GEODE-478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Barry Oglesby updated GEODE-478:
--------------------------------
    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:
{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.

  was:
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.

        Summary: Message class length field overflows if size is > 2GB  (was: Gateway sender
batch size in bytes could surpass 2GB and cause batch processing on the receiver to fail)

> 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: core
>            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)

Mime
View raw message