You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Marcus Eriksson (JIRA)" <ji...@apache.org> on 2018/12/06 09:51:00 UTC
[jira] [Comment Edited] (CASSANDRA-14554) LifecycleTransaction
encounters ConcurrentModificationException when used in multi-threaded
context
[ https://issues.apache.org/jira/browse/CASSANDRA-14554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16711204#comment-16711204 ]
Marcus Eriksson edited comment on CASSANDRA-14554 at 12/6/18 9:50 AM:
----------------------------------------------------------------------
bq. Marcus Eriksson: Could you take a look at this line? It looks like it was introduced in CASSANDRA-6696, but I'm not sure why?
with 6696 we might create sstablewriters but not write anything to them - say you have 2 disks but flush a single partition, the empty writer is then .abort:ed, but the full transaction is not, so we make sure the files are deleted by untrack:ing them. What I can't remember is why {{SSTableWriter#abort}} is not removing the files though, that feels like it would be the correct solution to the problem...
edit: We do the same in [SSTableRewriter|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/io/sstable/SSTableRewriter.java#L311] when we encounter an empty writer
was (Author: krummas):
bq. Marcus Eriksson: Could you take a look at this line? It looks like it was introduced in CASSANDRA-6696, but I'm not sure why?
with 6696 we might create sstablewriters but not write anything to them - say you have 2 disks but flush a single partition, the empty writer is then .abort:ed, but the full transaction is not, so we make sure the files are deleted by untrack:ing them. What I can't remember is why {{SSTableWriter#abort}} is not removing the files though, that feels like it would be the correct solution to the problem...
> LifecycleTransaction encounters ConcurrentModificationException when used in multi-threaded context
> ---------------------------------------------------------------------------------------------------
>
> Key: CASSANDRA-14554
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14554
> Project: Cassandra
> Issue Type: Bug
> Components: Streaming and Messaging
> Reporter: Dinesh Joshi
> Assignee: Dinesh Joshi
> Priority: Major
> Fix For: 4.0, 3.0.x, 3.11.x
>
>
> When LifecycleTransaction is used in a multi-threaded context, we encounter this exception -
> {quote}java.util.ConcurrentModificationException: null
> at java.util.LinkedHashMap$LinkedHashIterator.nextNode(LinkedHashMap.java:719)
> at java.util.LinkedHashMap$LinkedKeyIterator.next(LinkedHashMap.java:742)
> at java.lang.Iterable.forEach(Iterable.java:74)
> at org.apache.cassandra.db.lifecycle.LogReplicaSet.maybeCreateReplica(LogReplicaSet.java:78)
> at org.apache.cassandra.db.lifecycle.LogFile.makeRecord(LogFile.java:320)
> at org.apache.cassandra.db.lifecycle.LogFile.add(LogFile.java:285)
> at org.apache.cassandra.db.lifecycle.LogTransaction.trackNew(LogTransaction.java:136)
> at org.apache.cassandra.db.lifecycle.LifecycleTransaction.trackNew(LifecycleTransaction.java:529)
> {quote}
> During streaming we create a reference to a {{LifeCycleTransaction}} and share it between threads -
> [https://github.com/apache/cassandra/blob/5cc68a87359dd02412bdb70a52dfcd718d44a5ba/src/java/org/apache/cassandra/db/streaming/CassandraStreamReader.java#L156]
> This is used in a multi-threaded context inside {{CassandraIncomingFile}} which is an {{IncomingStreamMessage}}. This is being deserialized in parallel.
> {{LifecycleTransaction}} is not meant to be used in a multi-threaded context and this leads to streaming failures due to object sharing. On trunk, this object is shared across all threads that transfer sstables in parallel for the given {{TableId}} in a {{StreamSession}}. There are two options to solve this - make {{LifecycleTransaction}} and the associated objects thread safe, scope the transaction to a single {{CassandraIncomingFile}}. The consequences of the latter option is that if we experience streaming failure we may have redundant SSTables on disk. This is ok as compaction should clean this up. A third option is we synchronize access in the streaming infrastructure.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org