[
https://issues.apache.org/jira/browse/CASSANDRA-3578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13816355#comment-13816355
]
Benedict commented on CASSANDRA-3578:
-------------------------------------
bq. I am talking about count all the allocation and written, within a
segment.... Which is (A + B + C) != (A + B) (which means C or someone else is
still writing).
but this gets updated as you're reading, so unless you read allocationPosition
= writtenPosition = allocationPosition you can fail - and so you need to spin
until you see this three way check succeed, which I'm not keen on. Since they
are both being updated all the time, this could potentially mean a lengthy
period of spinning.
bq. Thats fine we will skip those, thats what the current implementation does
too
The current implementation never ACKs a message it cannot later replay under
batch, but this approach would permit that to happen.
> Multithreaded commitlog
> -----------------------
>
> Key: CASSANDRA-3578
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3578
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Jonathan Ellis
> Assignee: Vijay
> Priority: Minor
> Labels: performance
> Attachments: 0001-CASSANDRA-3578.patch, ComitlogStress.java,
> Current-CL.png, Multi-Threded-CL.png, 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)
