geode-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Darrel Schneider (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (GEODE-478) Gateway sender batch size in bytes could surpass 2GB and cause batch processing on the receiver to fail
Date Tue, 27 Oct 2015 17:01:27 GMT

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

Darrel Schneider updated GEODE-478:
-----------------------------------
    Description: 
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:
This bug is based on GEM-21, and this description is copied from there.

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.


> Gateway sender batch size in bytes could surpass 2GB and cause batch processing on the
receiver to fail
> -------------------------------------------------------------------------------------------------------
>
>                 Key: GEODE-478
>                 URL: https://issues.apache.org/jira/browse/GEODE-478
>             Project: Geode
>          Issue Type: Bug
>          Components: core
>            Reporter: Barry Oglesby
>
> 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