[jira] [Commented] (RATIS-139) RaftLogWorker should use two task queues.

["Jing Zhao (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/RATIS-139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16244933#comment-16244933 ] 

Jing Zhao commented on RATIS-139:
---------------------------------

[~jnp], have you seen a performance penalty with the current implementation? Here the scenario is different from editlog in HDFS, since the queue is a pending task queue instead of a pure data buffer. If you look at the types of the task, all the other tasks other than writelog may trigger a sync automatically. And if the queue contains more writelog task, then we can wait till the pendingflushnum hit forcesyncnum, or till the queue is empty, or we hit a finalizeSegment/truncate taks. Thoughts?

> RaftLogWorker should use two task queues. 
> ------------------------------------------
>
>                 Key: RATIS-139
>                 URL: https://issues.apache.org/jira/browse/RATIS-139
>             Project: Ratis
>          Issue Type: Improvement
>            Reporter: Jitendra Nath Pandey
>
> {code}
>   private boolean shouldFlush() {
>     return pendingFlushNum >= forceSyncNum ||
>         (pendingFlushNum > 0 && queue.isEmpty());
>   }
> {code}
> It is possible that queue is often non-empty, but not full to trigger force sync. We could use two queues similar to two buffer approach in HDFS edit logs.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)