[
https://issues.apache.org/jira/browse/CASSANDRA-1736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12931616#action_12931616
]
Jonathan Ellis commented on CASSANDRA-1736:
-------------------------------------------
One reason I don't think compaction marker belongs in components is that as
this bug highlights, we could end up with the marker as part of a snapshot.
Which would cause a more subtle bug. Here is the order of events:
{code}
My CFS has sstables A B C.
Flush introduces sstable D.
We begin compacting A B C D.
We begin iterating A B C D for snapshot.
During the iteration, compaction finishes producing sstable E. A B C D are
marked compacted.
snapshot finishes, with (say) C D marked compacted.
{code}
Now, the sstable tracker guarantees that we see a consistent view of the
sstables -- we will either exactly one of {A B C D} or {E}. But by mixing the
compaction marker in as a component we now have a snapshot that implies that A
and B were live but C and D were compacted, and if we take that snapshot as-is
and promote it to live data, when we restart Cassandra will purge C and D since
they were marked compacted.
We could band-aid this in a number of ways but I think the less fragile
approach is to treat the compaction marker as something separate from
components.
> ConcurrentModificationException when updating column family metadata
> --------------------------------------------------------------------
>
> Key: CASSANDRA-1736
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1736
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 0.7 beta 2
> Reporter: Jake Farrell
> Assignee: Stu Hood
> Fix For: 0.7.0
>
>
> From cli
> > update column family Tweet with column_metadata=[{column_name:state,
> > validation_class:UTF8Type}]
> > set Tweet [x][state] = TX
> > get Tweet where state = TX
> No index columns present
> > update column family Tweet with column_metadata=[{column_name:state,
> > index_type:0, validation_class:UTF8Type}]
> null
> > list Tweet
> java.net.SocketException: Broken pipe
> ERROR [MigrationStage:1] 2010-11-12 09:12:28,618 AbstractCassandraDaemon.java
> (line 90) Fatal exception in thread Thread[Migra$
> java.util.ConcurrentModificationException
> at java.util.HashMap$HashIterator.nextEntry(HashMap.java:793)
> at java.util.HashMap$KeyIterator.next(HashMap.java:828)
> at
> org.apache.cassandra.db.ColumnFamilyStore.snapshot(ColumnFamilyStore.java:1495)
> at
> org.apache.cassandra.db.migration.UpdateColumnFamily.beforeApplyModels(UpdateColumnFamily.java:76)
> at
> org.apache.cassandra.db.migration.Migration.apply(Migration.java:109)
> at
> org.apache.cassandra.thrift.CassandraServer$2.call(CassandraServer.java:672)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:619)
> ERROR [pool-1-thread-5] 2010-11-12 09:12:28,636 CustomTThreadPoolServer.java
> (line 175) Thrift error occurred during processin$
> org.apache.thrift.protocol.TProtocolException: Required field 'why' was not
> present! Struct: InvalidRequestException(why:null)
> at
> org.apache.cassandra.thrift.InvalidRequestException.validate(InvalidRequestException.java:340)
> at
> org.apache.cassandra.thrift.InvalidRequestException.write(InvalidRequestException.java:309)
> at
> org.apache.cassandra.thrift.Cassandra$system_update_column_family_result.write(Cassandra.java:26764)
> at
> org.apache.cassandra.thrift.Cassandra$Processor$system_update_column_family.process(Cassandra.java:3605)
> at
> org.apache.cassandra.thrift.Cassandra$Processor.process(Cassandra.java:2555)
> at
> org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:167)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:619)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
