You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@iotdb.apache.org by "Xiangdong Huang (Jira)" <ji...@apache.org> on 2021/02/06 03:46:00 UTC
[jira] [Commented] (IOTDB-1147) Concurrent in FlushManager cause
NoSuchElementException error
[ https://issues.apache.org/jira/browse/IOTDB-1147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17280068#comment-17280068 ]
Xiangdong Huang commented on IOTDB-1147:
----------------------------------------
hi, seems it only happens in the Debug log?
> Concurrent in FlushManager cause NoSuchElementException error
> --------------------------------------------------------------
>
> Key: IOTDB-1147
> URL: https://issues.apache.org/jira/browse/IOTDB-1147
> Project: Apache IoTDB
> Issue Type: Bug
> Components: Core/Engine
> Reporter: Houliang Qi
> Assignee: Houliang Qi
> Priority: Major
> Labels: pull-request-available
> Fix For: 0.12.0
>
> Attachments: image-2021-02-04-10-57-43-980.png, image-2021-02-04-10-57-53-288.png, image-2021-02-04-11-04-05-375.png
>
>
>
> When we flush one tsfile, we put the TsFileProcessor to the FlushManager, and use another thread pool to do the flush task of the memtables in this TsFileProcessor.
>
> Howerver, the following codes is not thread safe, because when the first code
> _tsFileProcessorQueue.isEmpty()_ is called, it may be return false, but instantly it maybe become empty due to consumed by the flush thread pool, so when called
> _tsFileProcessorQueue.getFirst().getStorageGroupName()_ it may cause NoSuchElementException error.
>
> What's worse, this causes a TsFile not to be closed all the time, causing the write to get stuck.
> !image-2021-02-04-10-57-43-980.png|width=811,height=251!
> The error are as follows:
>
> !image-2021-02-04-10-57-53-288.png|width=821,height=228!
>
> !image-2021-02-04-11-04-05-375.png|width=827,height=287!
--
This message was sent by Atlassian Jira
(v8.3.4#803005)