cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-4305) CF serialization failure when working with custom secondary indices.
Date Wed, 06 Jun 2012 14:17:23 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-4305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13290173#comment-13290173
] 

Sylvain Lebresne commented on CASSANDRA-4305:
---------------------------------------------

The fact is, guaranteeing that one can safely reuse a RM after apply() potentially limits
us on what optimization we can do internally (i.e. we, internally, may have to do copy to
offer the guarantee).

Besides, there is also the preserializedBuffers business inside RM that also make RM object
non-reusable. Applying an already applied mutation is a bug, because the commit log will use
the old version of the preserialized buffer. 

I also don't think that cloning a RM in the index code will be hugely expensive (but I do
agree that RM ought to have a cloneMe() method to make that simpler).
                
> CF serialization failure when working with custom secondary indices.
> --------------------------------------------------------------------
>
>                 Key: CASSANDRA-4305
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-4305
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.0.10
>            Reporter: Pavel Yaskevich
>              Labels: datastax_qa
>         Attachments: CASSANDRA-4305.patch
>
>
> Assertion (below) was triggered when client was adding new rows to Solr-backed secondary
indices (1000-row batch without any timeout).
> {noformat}
> ERROR [COMMIT-LOG-WRITER] 2012-05-30 16:39:02,896 AbstractCassandraDaemon.java (line
139) Fatal exception in thread Thread[COMMIT-LOG-WRITER,5,main]
> java.lang.AssertionError: Final buffer length 176 to accomodate data size of 123 (predicted
87) for RowMutation(keyspace='solrTest1338395932411', key='6b6579383039', modifications=[ColumnFamily(cf1
[long:false:8@1338395942384024,stringId:false:13@1338395940586003,])])
>         at org.apache.cassandra.utils.FBUtilities.serialize(FBUtilities.java:682)
>         at org.apache.cassandra.db.RowMutation.getSerializedBuffer(RowMutation.java:279)
>         at org.apache.cassandra.db.commitlog.CommitLogSegment.write(CommitLogSegment.java:122)
>         at org.apache.cassandra.db.commitlog.CommitLog$LogRecordAdder.run(CommitLog.java:600)
>         at org.apache.cassandra.db.commitlog.PeriodicCommitLogExecutorService$1.runMayThrow(PeriodicCommitLogExecutorService.java:49)
>         at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30)
>         at java.lang.Thread.run(Thread.java:662)
> {noformat}
> After investigation it was clear that it was happening because we were holding instances
of RowMutation queued to the addition to CommitLog to the actual "write" moment which is redundant.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message