[
https://issues.apache.org/jira/browse/CASSANDRA-6592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13885188#comment-13885188
]
Benedict commented on CASSANDRA-6592:
-------------------------------------
MemoryMeter itself is definitely threadsafe, and they all share the
Instrumentation, so making it ThreadLocal won't make those calls threadsafe.
The VM calls look threadsafe to me, anyway:
{code}
JvmtiEnv::GetObjectSize(jobject object, jlong* size_ptr) {
oop mirror = JNIHandles::resolve_external_guard(object);
NULL_CHECK(mirror, JVMTI_ERROR_INVALID_OBJECT);
if (mirror->klass() == SystemDictionary::Class_klass()) {
if (!java_lang_Class::is_primitive(mirror)) {
mirror = java_lang_Class::as_klassOop(mirror);
assert(mirror != NULL, "class for non-primitive mirror must exist");
}
}
*size_ptr = mirror->size() * wordSize;
return JVMTI_ERROR_NONE;
} /* end GetObjectSize */
klassOop java_lang_Class::as_klassOop(oop java_class) {
//%note memory_2
assert(java_lang_Class::is_instance(java_class), "must be a Class object");
klassOop k = klassOop(java_class->obj_field(_klass_offset));
assert(k == NULL || k->is_klass(), "type check");
return k;
}
{code}
It's possible the object being metered is being concurrently modified?
Certainly the CFMetaData permits this. And I note we measure it twice (one
minus the other), to really permit exploding the problem. In a BatchStatement
we might measure it many times. We should never measure something that is not
immutable if we want to get sensible results.
As an example, I would suggest something like the following in
ModificationStatement:
{code}
public long measureForPreparedCache(MemoryMeter meter)
{
return meter.measure(this) + meter.measureDeep(attrs)-
meter.measureDeep(boundTerms) + meter.measureDeep(processedKeys) +
meter.measureDeep(columnOperations);
}
{code}
> 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
>
>
> 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)
