[
https://issues.apache.org/jira/browse/IOTDB-439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17029513#comment-17029513
]
Tian Jiang commented on IOTDB-439:
----------------------------------
3. Currently, before one log is either timed out or committed, the next log is
blocked as the high concurrency is mainly supported by partitioning. As
operations in the same partition are basically serialized, this may not be a
big issue. So the current method "replaceLastLog" is enough.
Still, holding multiple uncommitted logs is still a future optimization.
> [Distributed] Incorrect Snapshot implementation and LogManager
> --------------------------------------------------------------
>
> Key: IOTDB-439
> URL: https://issues.apache.org/jira/browse/IOTDB-439
> Project: Apache IoTDB
> Issue Type: Sub-task
> Reporter: Xiangdong Huang
> Priority: Major
>
> I read the log/snapshot and manage packages in current cluster_new branch,
> and have some questions:
> 1. PartitionedSnapshotLogManager and FilePartitionedSnapshotLogManager are
> incorrect as
> a. they still store log into memory while the JavaDoc says they do not
> store data in memory.
> b. When doing snapshot, do they need to consider the part of the log in
> memory?
>
> 2. Current LogManager is not thread-safety. The caller (i.e., RaftMember)
> uses sync keyword to guarantee that for each call.
> a. a better design?
> b. is there any performance problem? as all operations are serialization.
>
> 3. Consider the Raft Protocol, don't we need APIs like
> `removeLogFrom(startIndex)` in LogManager? see the case of Figure 7 in Raft
> paper [1]
>
> [1] [https://raft.github.io/raft.pdf]
>
> [~jt2594838] may know clearly about current implementation.
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
