[ 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)