[ https://issues.apache.org/jira/browse/CASSANDRA-4305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13290155#comment-13290155 ]
Pavel Yaskevich commented on CASSANDRA-4305: -------------------------------------------- bq. Sure there is. Think of RM as a "builder" api, except we avoid actually copying to a new structure via build() for performance. "Once you pass it to another thread, don't modify it" is a totally reasonable rule. The flow in design that you describe is that you take RM as monolite structure but if you look at it from the angle of just being a container to be able persist the data inside it, than it becomes reasonable that user has all rights to modify objects that were given to that container after it was send to processing (probably to another thread) because RM should be responsible of keeping the state of internal structure constant, this applies clearly on indexes because if indexer wants to persist the state of the objects at some point in time and then go on processing them further (e.g. to store to some external component or return to the user) it shouldn't be forced to clone everything just because we don't preserve the state of RM (to avoid a single serialization). > 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