[ 
https://issues.apache.org/jira/browse/CASSANDRA-14554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dinesh Joshi updated CASSANDRA-14554:
-------------------------------------
    Description: 
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.

  was:
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 a multi-threaded context inside of {{CassandraIncomingFile}} which 
is a {{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.


> 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
>            Reporter: Dinesh Joshi
>            Assignee: Dinesh Joshi
>            Priority: Major
>
> 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-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

Reply via email to