cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <>
Subject [jira] [Updated] (CASSANDRA-6592) IllegalArgumentException when Preparing Statements
Date Wed, 29 Jan 2014 09:36:10 GMT


Sylvain Lebresne updated CASSANDRA-6592:

    Attachment: 0001-Remove-concurrent-use-of-MemoryMeter-instance.txt

Not sure what happens here. In particular the "is larger than allowed" exception suggests
MemoryMeter is sometimes returning something whack.  That being said, this sound like a race
(comments above suggests this doesn't reproduce reliably on a specific statement) and we do
use the same MemoryMeter instance concurrently. So while it's not clear why doing so would
be wrong, it's probably worth removing that variable from the equation and see if that fixes
it. So attaching a patch to switch to a ThreadLocal for the MemoryMeter. [~thobbs], since
you seem to be able to reproduce relatively easily, can you try said patch and see if it helps
or not?

If it doesn't, we might want to revert CASSANDRA-6107 until we understand what's going on.

> IllegalArgumentException when Preparing Statements
> --------------------------------------------------
>                 Key: CASSANDRA-6592
>                 URL:
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>            Reporter: Tyler Hobbs
>            Assignee: Lyuben Todorov
>            Priority: Critical
>             Fix For: 1.2.14, 2.0.5
>         Attachments: 0001-Remove-concurrent-use-of-MemoryMeter-instance.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
> {noformat}
> ERROR [Native-Transport-Requests:126] 2014-01-11 13:58:05,503 (line
210) Unexpected exception during request
> java.lang.IllegalArgumentException
>         at com.googlecode.concurrentlinkedhashmap.ConcurrentLinkedHashMap.checkArgument(
>         at com.googlecode.concurrentlinkedhashmap.ConcurrentLinkedHashMap$BoundedEntryWeigher.weightOf(
>         at com.googlecode.concurrentlinkedhashmap.ConcurrentLinkedHashMap.put(
>         at com.googlecode.concurrentlinkedhashmap.ConcurrentLinkedHashMap.put(
>         at org.apache.cassandra.cql3.QueryProcessor.storePreparedStatement(
>         at org.apache.cassandra.cql3.QueryProcessor.prepare(
>         at org.apache.cassandra.transport.messages.PrepareMessage.execute(
>         at org.apache.cassandra.transport.Message$Dispatcher.messageReceived(
>         at
>         at
>         at$DefaultChannelHandlerContext.sendUpstream(
>         at org.jboss.netty.handler.execution.ChannelUpstreamEventRunnable.doRun(
>         at
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(
>         at java.util.concurrent.ThreadPoolExecutor$
>         at
> {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

View raw message