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 16:36:23 GMT

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

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

Wait, there is two case:
# Either what you want to do in your 2ndary code is
{noformat}
ColumnFamily cf = ...
RowMutation rm = ...
rm.add(cf);
rm.apply();
cf.add(...);
{noformat}
and in that case, yes, moving the serialization to Table.apply() would allow that. But that's
the mono-threaded case, there is no concurrent sharing (from your point of view I mean). 
# or what you want to do is concurrent sharing, something like:
{noformat}
ColumnFamily cf = ...
pass cf to some other thread t2 that will modify cf at some point
RowMutation rm = ...
rm.add(cf);
rm.apply();
{noformat}
and in that case, moving the serialization to Table.apply() does not help, because maybe t2
will modify cf while apply() is serializing the mutation in the initial thread.

Now maybe you're talking of the first case, but sentences like "indexer was concurrently modifying
CF objects it previously passed to RM" made it sound like you're talking of case 2, so let's
be clear on what we're talking about.
                
> 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