cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benedict (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-6592) IllegalArgumentException when Preparing Statements
Date Wed, 29 Jan 2014 10:04:10 GMT

    [ 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)

Mime
View raw message