[
https://issues.apache.org/jira/browse/CASSANDRA-10202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15340800#comment-15340800
]
Ariel Weisberg commented on CASSANDRA-10202:
--------------------------------------------
bq. We also ideally want lock-free swapping-in of the new segment, no?
Currently we don't have it, but until we reach pure-TPC (probably never) en
route fewer application threads exposes us to a higher risk of gumming up the
system.
This is the part I don't follow. It's an operation that occurs every N writes,
when the segment needs swapping, and the operation itself is generally going to
be fast because the segment will already exist so it shouldn't have to wait on
anything or even make a system call.
Most allocations will only have to do a volatile read to fetch the current
segment and an atomic increment on the segment's offset value, or whatever it's
labeled inside each segment, and only if that fails or there is no space will
it have to lock and check the condition.
TPC doesn't mean you have to religiously remove every single lock in the system
just the ones that are frequently contended or held a long time. IOW anything
that will cause stalls. Either fewer long stalls, or many small stalls. It will
be a while before we get whacked by Amdahl in this case.
I know you know this already. I am just stating the reasoning I think should be
applied in this case. Were the bugs related to concurrency or was it just
incorrect handling of the spare segments and allocation in general? It was
always pretty finicky looking.
> simplify CommitLogSegmentManager
> --------------------------------
>
> Key: CASSANDRA-10202
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10202
> Project: Cassandra
> Issue Type: Improvement
> Components: Local Write-Read Paths
> Reporter: Jonathan Ellis
> Assignee: Branimir Lambov
> Priority: Minor
>
> Now that we only keep one active segment around we can simplify this from the
> old recycling design.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
