chengjianyun commented on issue #3954:
URL: https://github.com/apache/iotdb/issues/3954#issuecomment-919876433
> No bug for now does not mean no bug forever. And different situations and
applications expose different problems. The important thing is building our own
verification instead of trusting others just because they have tested on their
own cases.
>
> I am more than sure that we will have to face some bugs whatever we use,
and if just several bugs would make you lose your heart, I think it is probably
not likely you will build any confidence in your own creation, and you may
never get near the core of some technologies.
I think the discussion out of the scope, let's narrow down the scope to the
topic. IMO, IoTDB is a production, when we deliver the production to user, we
need to tell user how good/bad are we. It's nothing to do with technologies or
confidence. Many production are based on others implementation such as TiKV
depends on RocksDB which opensourced by Facebook. Raft library is only a tool,
import it could reduce unnecessary works and provide a relative high confidence
module to sync data to different node.
> I am not sure about what you mean by async append, but we have async
apply. And we are very serious about performance problems as performance is one
of the few advantages of IoTDB and why we would want to build our own
consensus. Otherwise, why do you think we would bother so much. We want to
continue this advantage instead of handing it out to others.
Agree that the performance is one of the advantages. But even the fastest
vehicle should be safe in my understanding. Do you agree this?
`Async append` means leader can append log locally and broadcast log
parallelly.
For `async apply`, not sure my understanding is right or not, but according
code, I think it's sync in current IoTDB implemenation. The `appendEntries`
acquires lock of `logManager` until get response which means apply complete.
And `applyEntries` in RaftLogManager is also a sync operation. Correct me if my
understanding is wrong.
```
appendEntries in RaftManager:
private long appendEntries(long prevLogIndex, long prevLogTerm, long
leaderCommit, List<Log> logs) {
// ... ignore lines
synchronized (logManager) {
long startTime =
Timer.Statistic.RAFT_RECEIVER_APPEND_ENTRY.getOperationStartTime();
resp = logManager.maybeAppend(prevLogIndex, prevLogTerm, leaderCommit,
logs);
Timer.Statistic.RAFT_RECEIVER_APPEND_ENTRY.calOperationCostTimeFromStart(startTime);
if (resp != -1) {
if (logger.isDebugEnabled()) {
logger.debug("{} append a new log list {}, commit to {}", name,
logs, leaderCommit);
}
resp = Response.RESPONSE_AGREE;
} else {
// the incoming log points to an illegal position, reject it
resp = Response.RESPONSE_LOG_MISMATCH;
}
}
return resp;
}
// applyEntries in RaftLogManager
void applyEntries(List<Log> entries) {
for (Log entry : entries) {
applyEntry(entry);
}
}
public void applyEntry(Log entry) {
// For add/remove logs in data groups, this log will be applied
immediately when it is
// appended to the raft log.
// In this case, it will apply a log that has been applied.
if (entry.isApplied()) {
return;
}
if (blockAppliedCommitIndex > 0 && entry.getCurrLogIndex() >
blockAppliedCommitIndex) {
blockedUnappliedLogList.add(entry);
return;
}
try {
logApplier.apply(entry);
} catch (Exception e) {
entry.setException(e);
entry.setApplied(true);
}
}
```
> I do not understand why you insist that Raft logic is mixed with business
logic, as far as I know, only the implementations of partition table and
applier concern how stand-alone IoTDB works, and they are already made
interface. Most parts of the cluster module can work without any interference
with the standalone part, and can also be tested as any raft implementation.
I think we could have a much clear interface definitions and responsibility
boundary if we can refine the abstract of Raft implementation. E.g.
`DataGroupMember` and `MetaGroupMember` are extend from `RaftMember`, but
`RaftMember` mainly handles Raft related logic such as appendEntry. But
`DataGroupMember` and `MetaGroupMember` are handlers of application logic such
as query or non-query plans.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
