[
https://issues.apache.org/jira/browse/IOTDB-637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17225181#comment-17225181
]
Jialin Qiao commented on IOTDB-637:
-----------------------------------
https://github.com/apache/iotdb/pull/1524
> Improper lock level and (maybe) error in ActiveTimeSeriesCounter
> -----------------------------------------------------------------
>
> Key: IOTDB-637
> URL: https://issues.apache.org/jira/browse/IOTDB-637
> Project: Apache IoTDB
> Issue Type: Bug
> Components: Core/Engine
> Affects Versions: 0.10.0
> Reporter: Xiangdong Huang
> Priority: Major
>
> When a SG is flushed, the updateActiveRatio() of
> ActiveTimeSeriesCounter.class will be called.
> The function executes the following 2 steps:
> # calculate the new active time series ratio in recently flushed memtable;
> # reset the info for calculating the active ratio in next memtable.
> The question is, we may have 2 (or more) memtables for each SG. While one
> enqueues the flushing queue, the other may have already received data. If so,
> after the first memtable is flushed, the info in ActiveTimeSeriesCounter will
> be reset and therefore the info about the second memtable is lost.
>
> The above case is more each to appear when the time range partition feature
> is enabled. In this case, a SG may have several subSGs (while each one
> represents a time range of the SG).
>
> Lock Level:
> # As all maps are concurrency maps, there is not need to use lock in
> getActiveRatio();
> # `storageGroupHllMap.get(storageGroup).cardinality();` is not O(1)
> operation, we can reduce the cover scope of the lock in updateActiveRatio(),
> maybe we can require the lock only when `activeTimeSeriesNum !=
> activeTimeSeriesNumMap.get(storageGroup)` == true.
> How do you think? [~liurui]
>
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
