[
https://issues.apache.org/jira/browse/CASSANDRA-6592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13885247#comment-13885247
]
Benedict commented on CASSANDRA-6592:
-------------------------------------
Yeah, whilst I think measuring CFM is dangerous (certainly it could lead to the
negative numbers) I'm suspicious of that being the cause for such dramatic
spikes.
If you try using the jamm-0.2.6.jar I included in CASSANDRA-5549 you could try
running with different estimation strategies - if either of the guess*
strategies give nonsense, it's either JAMM doing something weird internally
(unlikely) or some weird interaction of mutating object being passed into it
(still most plausible). If they don't, it might be Instrumentation after all,
but looking at the hotspot code that seems the least likely of all.
*Note the "unsafe" guess is perfectly accurate, as far as I could test with
extensive random class generation, so it's not actually particularly guess-y.
> 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: Lyuben Todorov
> Priority: Critical
> Fix For: 1.2.14, 2.0.5
>
> Attachments: 0001-Remove-concurrent-use-of-MemoryMeter-instance.txt,
> 0001-Switch-to-adding-fields-manually-in-measureForPrepared.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)
