[
https://issues.apache.org/jira/browse/RATIS-406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16686937#comment-16686937
]
Lokesh Jain commented on RATIS-406:
-----------------------------------
[~szetszwo] Thanks for working on this! I had a few thoughts on
RaftServerImpl#appendEntriesAsync.
# RaftLogWorker uses a blocking queue which blocks the thread in addIOTask
function if queue is full. I think instead of blocking the thread we should
just fail the operation. RaftLogWorker#addIOTask is invoked via appendEntry
call.
{code:java}
futures = state.getLog().append(entries);
{code}
In such a case we can safely include the append entries inside the lock by
making sure it does not block the thread?
# I think we can get rid of the lock on RaftServerImpl in latter part of the
function. We take a lock for updating the state machine.
> In RaftServerImpl, the RaftLog.append(entries) call should not hold the
> RaftServerImpl lock
> -------------------------------------------------------------------------------------------
>
> Key: RATIS-406
> URL: https://issues.apache.org/jira/browse/RATIS-406
> Project: Ratis
> Issue Type: Improvement
> Components: server
> Reporter: Tsz Wo Nicholas Sze
> Assignee: Tsz Wo Nicholas Sze
> Priority: Major
> Attachments: r406_20181109.patch, r406_20181113.patch
>
>
> In RaftServerImpl, the appendEntriesAsync(..) calls must be sequential
> (although the actual log I/O is async). Otherwise, the entries appended may
> be out of order.
> As a result, RaftLog.append(entries) needs not to hold the RaftServerImpl
> lock.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
