[
https://issues.apache.org/jira/browse/CASSANDRA-3578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13835914#comment-13835914
]
Benedict commented on CASSANDRA-3578:
-------------------------------------
bq. My point is that the "no room" case can be a false positive when
discardUnusedTail has consumed space that isn't actually written to.
Check out sync() (the bit inside if (nextMarker < 0) { }) - we check for this
by checking the discardedTailFrom property, and write a marker if there's room
at the start of the discarded region.
bq. Which part? The nonclemature is obviously correct this way.
We point next to next, which is absolutely correct! In my book, though maybe we
have different books :-) The nextMarker we define in the sync() method is the
*next* value we want to set the nextSyncMarkerPosition, and it is also the next
sync marker we will write a length to at the next sync (during the current sync
we only zero it). Although you could legitimately consider it the previous tail
marker, I don't because I consider the file to be a list of effectively
[length:data][length:data][0:undefined]. The tail marker is a convenience of an
unitialised head marker. I would prefer to rename the local variable 'offset'
to 'lastMarker'
The isFullySynced() is necessary to avoid the race condition you raised in your
previous comment.
> Multithreaded commitlog
> -----------------------
>
> Key: CASSANDRA-3578
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3578
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Jonathan Ellis
> Assignee: Benedict
> Priority: Minor
> Labels: performance
> Attachments: 0001-CASSANDRA-3578.patch, ComitlogStress.java,
> Current-CL.png, Multi-Threded-CL.png, TestEA.java, latency.svg, oprate.svg,
> parallel_commit_log_2.patch
>
>
> Brian Aker pointed out a while ago that allowing multiple threads to modify
> the commitlog simultaneously (reserving space for each with a CAS first, the
> way we do in the SlabAllocator.Region.allocate) can improve performance,
> since you're not bottlenecking on a single thread to do all the copying and
> CRC computation.
> Now that we use mmap'd CommitLog segments (CASSANDRA-3411) this becomes
> doable.
> (moved from CASSANDRA-622, which was getting a bit muddled.)
--
This message was sent by Atlassian JIRA
(v6.1#6144)
