cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-5981) Netty frame length exception when storing data to Cassandra using binary protocol
Date Fri, 06 Sep 2013 14:59:51 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-5981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13760243#comment-13760243
] 

Sylvain Lebresne commented on CASSANDRA-5981:
---------------------------------------------

bq. Is this something that should be configurable or is this a hard limit that will prevent
batch statements of this size from executing for some reason?

Sending a message of more than 256mb is a fairly bad idea tbh. Cassandra is just not optimized
for that kind of huge request and so you will run into problems and get bad performance if
you try to do even if we were lifting the hard coded limit. In fact, the only reason for this
limit is to protect the server from OOM if the client sends something clearly wrong.

That being said, I'm not totally opposed to making the limit configurable. But more because
I think most people may want to make it lower rather than higher.
                
> Netty frame length exception when storing data to Cassandra using binary protocol
> ---------------------------------------------------------------------------------
>
>                 Key: CASSANDRA-5981
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-5981
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>         Environment: Linux, Java 7
>            Reporter: Justin Sweeney
>            Assignee: Sylvain Lebresne
>            Priority: Minor
>
> Using Cassandra 1.2.8, I am running into an issue where when I send a large amount of
data using the binary protocol, I get the following netty exception in the Cassandra log file:
> {quote}
> ERROR 09:08:35,845 Unexpected exception during request
> org.jboss.netty.handler.codec.frame.TooLongFrameException: Adjusted frame length exceeds
268435456: 292413714 - discarded
>         at org.jboss.netty.handler.codec.frame.LengthFieldBasedFrameDecoder.fail(LengthFieldBasedFrameDecoder.java:441)
>         at org.jboss.netty.handler.codec.frame.LengthFieldBasedFrameDecoder.failIfNecessary(LengthFieldBasedFrameDecoder.java:412)
>         at org.jboss.netty.handler.codec.frame.LengthFieldBasedFrameDecoder.decode(LengthFieldBasedFrameDecoder.java:372)
>         at org.apache.cassandra.transport.Frame$Decoder.decode(Frame.java:181)
>         at org.jboss.netty.handler.codec.frame.FrameDecoder.callDecode(FrameDecoder.java:422)
>         at org.jboss.netty.handler.codec.frame.FrameDecoder.messageReceived(FrameDecoder.java:303)
>         at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:268)
>         at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:255)
>         at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:84)
>         at org.jboss.netty.channel.socket.nio.AbstractNioWorker.processSelectedKeys(AbstractNioWorker.java:472)
>         at org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:333)
>         at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:35)
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
>         at java.lang.Thread.run(Thread.java:722)
> {quote}
> I am using the Datastax driver and using CQL to execute insert queries. The query that
is failing is using atomic batching executing a large number of statements (~55).
> Looking into the code a bit, I saw that in the org.apache.cassandra.transport.Frame$Decoder
class, the MAX_FRAME_LENGTH is hard coded to 256 mb.
> Is this something that should be configurable or is this a hard limit that will prevent
batch statements of this size from executing for some reason?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message