[
https://issues.apache.org/jira/browse/CASSANDRA-4305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13290184#comment-13290184
]
Pavel Yaskevich commented on CASSANDRA-4305:
--------------------------------------------
bq. It's deeply silly to make arguments based on abstract conceptions of
"users." This is an internal API, with a very narrow use case. As I said
initially, it's neither practical nor desirable to try to allow index
implementers to remain ignorant of all Cassandra internals.
I don't make arguments on the conception of "users" indeed I make them on the
particular design you have described in your previous comment. The silly is to
advocate bug as implementation detail which could lead to hardly reproducible
assertion errors in different parts of the system. I'm not trying to make RM
reusable, nothing of that sort, the problem in RM is in fact that it should
properly preserve the state of internal objects once it's created but it
doesn't do that. Nobody was trying to re-use or re-apply RM in index code but
instead was changing (adding columns) to some of the ColumnFamily objects that
is passed by-reference to RM. That "changing" was done separately to be able to
properly populate external structure (in that case Solr Document) without
coping the whole contents of CF and *none* of those changes was intended to be
persisted (included into RM) which lead to this concurrency bug from
description where CL was trying to serialize the RM while indexer was
concurrently modifying CF objects it previously passed to RM.
> 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
