[
https://issues.apache.org/jira/browse/CASSANDRA-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12735243#action_12735243
]
Jonathan Ellis commented on CASSANDRA-182:
------------------------------------------
07
switch to arrayblockingqueue; it's a little cleaner and performance seems
unaffected
06
config options. increasing write threads to 32 (was 4) allows performance
to be mostly decent again, especially if you crank the delay up to 10ms
05
custom CommitLogExecutorService that can fsync per multiple CL additions
04
threadpoolexecutor, just using an out-of-the-box executor as a first step
03
naive fsync-after-each-log-entry. performance _sucks._
02
mv AbstractWriter to its own top-level class and remove redundant
IFileWriter
01
handle incomplete CL entries on recover (a fairly important bug fix)
> CommitLog.add doesn't really force to disk
> ------------------------------------------
>
> Key: CASSANDRA-182
> URL: https://issues.apache.org/jira/browse/CASSANDRA-182
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 0.3
> Reporter: Sandeep Tata
> Assignee: Jonathan Ellis
> Fix For: 0.4
>
> Attachments:
> 0001-CASSANDRA-182-handle-incomplete-CL-entries-on-recover.txt,
> 0002-mv-AbstractWriter-to-its-own-top-level-class-and-remov.txt,
> 0003-naive-fsync-after-each-log-entry.txt, 0004-threadpoolexecutor.txt,
> 0005-custom-CommitLogExecutorService-that-can-fsync-per-mul.txt,
> 0006-config-options.txt, 0007-arrayblockingqueue.txt, CASSANDRA-182.patch
>
>
> CommitLog.add does't really force writes to disk. This could result in acked
> writes being lost.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
