[
https://issues.apache.org/jira/browse/RATIS-477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16756700#comment-16756700
]
Vladimir Rodionov edited comment on RATIS-477 at 1/31/19 12:00 AM:
-------------------------------------------------------------------
Josh, how are you going to resolve read(3) call? You will need to iterate
through *all* log entries again. Correct? What I suggest:
1. Change read log API to accommodate possible multiple return log entries.
For example:
{code}
long logId = write(List<ByteBuffer> entries)
Then you can call read:
List<ByteBuffer> entries = read(logId);
{code}
Read can return multiple entries if corresponding write was batch write for
this particular *logId*. I would change read API by keeping only one method:
{code}
long nextId = read(List<ByteBuffer> buffer, int logId)
{code}
The API call returns nextId to read, *buffer* list size can be increased by
implementation if a given size can't accommodate all log entries in this
particular raft log entry (side effect), if there are no log service entries in
this Raft ID entry, then we iterate until we get real log entries.
Batch read API is not necessary, as since if we use batch writes, we will
always get batch reads.
was (Author: vrodionov):
Josh, how are you going to resolve read(3) call? You will need to iterate
through *all* log entries again. Correct? What I suggest:
1. Change read log API to accommodate possible multiple return log entries.
For example:
{code}
long logId = write(List<ByteBuffer> entries)
Then you can call read:
List<ByteBuffer> entries = read(logId);
{code}
Read can return multiple entries if corresponding write was batch write for
this particular *logId*. I would change read API by keeping only one method:
{code}
long nextId = read(List<ByteBuffer> buffer, int logId)
{code}
The API call returns nextId to read, *buffer* list size can be increased by
implementation if a given size can't accomodate all log entries in this
particular raft log entry (side effect), if there are no log service entries in
this Raft ID entry, then we iterate until we get real log entries.
> Improve LogStateMachine.processReadRequest()
> --------------------------------------------
>
> Key: RATIS-477
> URL: https://issues.apache.org/jira/browse/RATIS-477
> Project: Ratis
> Issue Type: Improvement
> Components: LogService
> Reporter: Josh Elser
> Assignee: Josh Elser
> Priority: Major
> Fix For: 0.4.0
>
>
> [~vrodionov] and [~rajeshbabu] were asking about this in RATIS-470. Can we
> improve the logic that reads through the "head" of the RaftLog to find the
> "LogService offset"?
> Vlad suggested:
> {quote}
> Josh, can we simplify this a little bit? Client gets Raft log ID one every
> append, for multi-get calls we can use this LogID (RAFT) as our start log ID
> to avoid iterating through all logs, then you can unwind log entries by using
> new logic, see above:
> int numRecordsInAppend = append.getDataCount();
> There is no need to iterate from the very beginning
> {quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
