[
https://issues.apache.org/jira/browse/CASSANDRA-6592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14171719#comment-14171719
]
Kishan Karunaratne edited comment on CASSANDRA-6592 at 10/14/14 11:40 PM:
--------------------------------------------------------------------------
I got the same error message as well, while (ironically) working on the ruby
duration test. Here are some sample messages:
{noformat}
Prepared statement of size 4451848 bytes is larger than allowed maximum of
2027520 bytes.
Prepared statement of size 4434568 bytes is larger than allowed maximum of
2027520 bytes.
This is my schema, and the offending prepare statement:
{noformat}
@session.execute("CREATE TABLE duration_test.ints (
key INT,
copy INT,
value INT,
PRIMARY KEY (key, copy))"
)
select = @session.prepare("SELECT * FROM ints WHERE key=?")
Now, I notice that if I explicitly specify the keyspace in the prepare, I don't
get the error.
was (Author: kishkaru):
I got the same error message as well, while (ironically) working on the ruby
duration test. Here are some sample messages:
{noformat}
Prepared statement of size 4451848 bytes is larger than allowed maximum of
2027520 bytes.
{noformat}
Prepared statement of size 4434568 bytes is larger than allowed maximum of
2027520 bytes.
This is my schema, and the offending prepare statement:
{noformat}
@session.execute("CREATE TABLE duration_test.ints (
key INT,
copy INT,
value INT,
PRIMARY KEY (key, copy))"
)
select = @session.prepare("SELECT * FROM ints WHERE key=?")
Now, I notice that if I explicitly specify the keyspace in the prepare, I don't
get the error.
> IllegalArgumentException when Preparing Statements
> --------------------------------------------------
>
> Key: CASSANDRA-6592
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6592
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Reporter: Tyler Hobbs
> Assignee: Sylvain Lebresne
> Priority: Critical
> Fix For: 1.2.14, 2.0.5
>
> Attachments: 6592-2.0.txt
>
>
> When preparing a lot of statements with the python native driver, I
> occasionally get an error response with an error that corresponds to the
> following stacktrace in the cassandra logs:
> {noformat}
> ERROR [Native-Transport-Requests:126] 2014-01-11 13:58:05,503
> ErrorMessage.java (line 210) Unexpected exception during request
> java.lang.IllegalArgumentException
> at
> com.googlecode.concurrentlinkedhashmap.ConcurrentLinkedHashMap.checkArgument(ConcurrentLinkedHashMap.java:259)
> at
> com.googlecode.concurrentlinkedhashmap.ConcurrentLinkedHashMap$BoundedEntryWeigher.weightOf(ConcurrentLinkedHashMap.java:1448)
> at
> com.googlecode.concurrentlinkedhashmap.ConcurrentLinkedHashMap.put(ConcurrentLinkedHashMap.java:764)
> at
> com.googlecode.concurrentlinkedhashmap.ConcurrentLinkedHashMap.put(ConcurrentLinkedHashMap.java:743)
> at
> org.apache.cassandra.cql3.QueryProcessor.storePreparedStatement(QueryProcessor.java:255)
> at
> org.apache.cassandra.cql3.QueryProcessor.prepare(QueryProcessor.java:221)
> at
> org.apache.cassandra.transport.messages.PrepareMessage.execute(PrepareMessage.java:77)
> at
> org.apache.cassandra.transport.Message$Dispatcher.messageReceived(Message.java:287)
> at
> org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70)
> at
> org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)
> at
> org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791)
> at
> org.jboss.netty.handler.execution.ChannelUpstreamEventRunnable.doRun(ChannelUpstreamEventRunnable.java:43)
> at
> org.jboss.netty.handler.execution.ChannelEventRunnable.run(ChannelEventRunnable.java:67)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
> at java.lang.Thread.run(Thread.java:662)
> {noformat}
> Looking at the CLHM source, this means we're giving the statement a weight
> that's less than 1. I'll also note that these errors frequently happen in
> clumps of 2 or 3 at a time.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
