[jira] [Commented] (IOTDB-637) Improper lock level and (maybe) error in ActiveTimeSeriesCounter

["Jialin Qiao (Jira)" <ji...@apache.org>]

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