[
https://issues.apache.org/jira/browse/CASSANDRA-6592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13887782#comment-13887782
]
Benedict commented on CASSANDRA-6592:
-------------------------------------
I think I have just sussed this bug out at last.
And it would have also been fixed by CASSANDRA-5549 if I'm correct (well,
except for a brief risk period at startup). This fix is still the best solution.
The Metering of Memtable memory occupancy iterated over the entire Memtable,
which included its fields, which included its ColumnFamilyStore, which included
its CompactionStrategy. Since the metering uses reflection to iterate over the
fields of the CompactionStrategy, the CompactionStrategy's class would have its
SoftReference<Field> set whenever this enumeration occured. A GC would clear
these references. The CFMetaData has a reference to this _Class_ object, and so
if the two measurements happened across a GC, we would get different values.
Note this cannot explain the absurdly large values, but since we currently
think they might be something else, I feel comfortable that this is a
satisfactory explanation for the reason behind this, and why it would reoccur
but also why it was infrequent.
> 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.1.5#6160)
