[jira] [Assigned] (IOTDB-5468) Add the io util of each disk in the metric model
[ https://issues.apache.org/jira/browse/IOTDB-5468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Houliang Qi reassigned IOTDB-5468: -- Assignee: Sixing Wu > Add the io util of each disk in the metric model > > > Key: IOTDB-5468 > URL: https://issues.apache.org/jira/browse/IOTDB-5468 > Project: Apache IoTDB > Issue Type: Wish > Components: Core/Engine >Reporter: Houliang Qi >Assignee: Sixing Wu >Priority: Major > > Add the io util of each device in the metric model, which can helper the dba > to analyze some issues. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IOTDB-5468) Add the io util of each disk in the metric model
Houliang Qi created IOTDB-5468: -- Summary: Add the io util of each disk in the metric model Key: IOTDB-5468 URL: https://issues.apache.org/jira/browse/IOTDB-5468 Project: Apache IoTDB Issue Type: Wish Components: Core/Engine Reporter: Houliang Qi Add the io util of each device in the metric model, which can helper the dba to analyze some issues. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IOTDB-5447) ConcurrentModificationException occurred when initializating for fragment instance
[ https://issues.apache.org/jira/browse/IOTDB-5447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Houliang Qi reassigned IOTDB-5447: -- Assignee: Houliang Qi > ConcurrentModificationException occurred when initializating for fragment > instance > > > Key: IOTDB-5447 > URL: https://issues.apache.org/jira/browse/IOTDB-5447 > Project: Apache IoTDB > Issue Type: Bug > Components: Core/Query >Affects Versions: 1.0.0 >Reporter: Houliang Qi >Assignee: Houliang Qi >Priority: Major > Labels: pull-request-available > Attachments: image-2023-02-01-15-38-17-900.png > > > !image-2023-02-01-15-38-17-900.png! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IOTDB-5447) ConcurrentModificationException occurred when initializating for fragment instance
Houliang Qi created IOTDB-5447: -- Summary: ConcurrentModificationException occurred when initializating for fragment instance Key: IOTDB-5447 URL: https://issues.apache.org/jira/browse/IOTDB-5447 Project: Apache IoTDB Issue Type: Bug Reporter: Houliang Qi Attachments: image-2023-02-01-15-38-17-900.png !image-2023-02-01-15-38-17-900.png! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IOTDB-5356) The display result of show region command will cause confusion
Houliang Qi created IOTDB-5356: -- Summary: The display result of show region command will cause confusion Key: IOTDB-5356 URL: https://issues.apache.org/jira/browse/IOTDB-5356 Project: Apache IoTDB Issue Type: Improvement Components: Core/Engine Reporter: Houliang Qi Attachments: image-2023-01-04-16-33-58-097.png, image-2023-01-04-16-36-02-719.png In version 1.0, when we use show regions command, the display of the command may confuse the user. As shown below, the different schema regions have the same series slot id. which is inconsistent with code. !image-2023-01-04-16-36-02-719.png! !image-2023-01-04-16-33-58-097.png! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IOTDB-5356) The display result of show region command will cause confusion
[ https://issues.apache.org/jira/browse/IOTDB-5356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Houliang Qi reassigned IOTDB-5356: -- Assignee: Yongzao Dan > The display result of show region command will cause confusion > -- > > Key: IOTDB-5356 > URL: https://issues.apache.org/jira/browse/IOTDB-5356 > Project: Apache IoTDB > Issue Type: Improvement > Components: Core/Engine >Reporter: Houliang Qi >Assignee: Yongzao Dan >Priority: Major > Attachments: image-2023-01-04-16-33-58-097.png, > image-2023-01-04-16-36-02-719.png > > > In version 1.0, when we use show regions command, the display of the command > may confuse the user. > As shown below, the different schema regions have the same series slot id. > which is inconsistent with code. > !image-2023-01-04-16-36-02-719.png! > !image-2023-01-04-16-33-58-097.png! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IOTDB-5111) [ ratis ] Data is distributed across disks ，after the cluster is restarted, all data is lost
[
https://issues.apache.org/jira/browse/IOTDB-5111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17653841#comment-17653841
]
Houliang Qi commented on IOTDB-5111:
Hi, data loss is *BIG* issue in the product environment, so when does the issue
happen? if the user specifies multi dn_data_dirs which across many disks, will
this happen?
> [ ratis ] Data is distributed across disks ，after the cluster is restarted,
> all data is lost
>
>
> Key: IOTDB-5111
> URL: https://issues.apache.org/jira/browse/IOTDB-5111
> Project: Apache IoTDB
> Issue Type: Bug
> Components: mpp-cluster
>Affects Versions: 1.0.0
>Reporter: 刘珍
>Assignee: Song Ziyang
>Priority: Major
> Attachments: image-2022-12-02-17-58-45-096.png,
> image-2022-12-02-17-59-05-010.png
>
>
> rel/1.0
> config/schema/data 3个协议均是ratis，
> dn_data_dirs=data/datanode/data,/data1/iotdb/datanode/data
> 跨盘存储，
> 写入数据，重启集群，{color:#DE350B}*数据全部丢失*{color}。
> 还有1个问题，{color:#DE350B}snapshot目录下依然有.tmp.文件夹名称{color}：
> !image-2022-12-02-17-59-05-010.png!
> 测试环境-私有云1期 8C32GB
> 1. 3副本3C7D
> Common
> data_region_consensus_protocol_class=org.apache.iotdb.consensus.ratis.RatisConsensus
> schema_replication_factor=3
> data_replication_factor=3
> wal_buffer_size_in_byte=1048576
> max_waiting_time_when_insert_blocked=360
> query_timeout_threshold=3600
> ConfigNode
> MAX_HEAP_SIZE="20G"
> MAX_DIRECT_MEMORY_SIZE="6G"
> DataNode
> MAX_HEAP_SIZE="20G"
> MAX_DIRECT_MEMORY_SIZE="6G"
> dn_data_dirs=data/datanode/data,/data1/iotdb/datanode/data
> 2. 启动BM 写入数据
> GROUP_NUMBER=1
> DEVICE_NUMBER=1000
> REAL_INSERT_RATE=1.0
> SENSOR_NUMBER=1000
> IS_SENSOR_TS_ALIGNMENT=true
> IS_OUT_OF_ORDER=false
> OUT_OF_ORDER_RATIO=0.5
> OPERATION_PROPORTION=1:0:0:0:0:0:0:0:0:0:0
> CLIENT_NUMBER=50
> LOOP=1
> BATCH_SIZE_PER_WRITE=10
> START_TIME=2018-8-30T00:00:00+08:00
> POINT_STEP=200
> OP_MIN_INTERVAL=0
> OP_MIN_INTERVAL_RANDOM=false
> INSERT_DATATYPE_PROPORTION=1:1:1:1:1:1
> ENCODINGS=PLAIN/PLAIN/PLAIN/PLAIN/PLAIN/PLAIN
> COMPRESSOR=SNAPPY
> IS_DELETE_DATA=false
> CREATE_SCHEMA=true
> BENCHMARK_CLUSTER=false
> !image-2022-12-02-17-58-45-096.png!
> 3. 重启集群
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IOTDB-5305) The slow query log can not display the sql statement
Houliang Qi created IOTDB-5305: -- Summary: The slow query log can not display the sql statement Key: IOTDB-5305 URL: https://issues.apache.org/jira/browse/IOTDB-5305 Project: Apache IoTDB Issue Type: Improvement Components: Core/Query Reporter: Houliang Qi Attachments: image-2022-12-28-13-00-50-738.png !image-2022-12-28-13-00-50-738.png! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IOTDB-5299) The metrics of the size of files is incorrect when the datanode restart
Houliang Qi created IOTDB-5299: -- Summary: The metrics of the size of files is incorrect when the datanode restart Key: IOTDB-5299 URL: https://issues.apache.org/jira/browse/IOTDB-5299 Project: Apache IoTDB Issue Type: Bug Components: Core/Engine Reporter: Houliang Qi Attachments: image-2022-12-28-09-54-48-013.png The size of the file is incorrect when the datanode restart in the metrics dashbord. it will begin with zero. !image-2022-12-28-09-54-48-013.png! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IOTDB-5261) The number of clients in client pool of AsyncIoTConsensusServiceClient can not be changed through dn_max_connection_for_internal_service
[ https://issues.apache.org/jira/browse/IOTDB-5261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Houliang Qi reassigned IOTDB-5261: -- Assignee: Houliang Qi > The number of clients in client pool of AsyncIoTConsensusServiceClient can > not be changed through dn_max_connection_for_internal_service > > > Key: IOTDB-5261 > URL: https://issues.apache.org/jira/browse/IOTDB-5261 > Project: Apache IoTDB > Issue Type: Bug > Components: Core/Server >Affects Versions: 1.0.0 >Reporter: Houliang Qi >Assignee: Houliang Qi >Priority: Major > Attachments: image-2022-12-21-17-16-13-037.png > > > The number of clients in the client pool of AsyncIoTConsensusServiceClient > can not be changed through _dn_max_connection_for_internal_service_ > we change the _dn_max_connection_for_internal_service_ to 500, however it not > take effect. > _!image-2022-12-21-17-16-13-037.png!_ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IOTDB-5261) The number of clients in client pool of AsyncIoTConsensusServiceClient can not be changed through dn_max_connection_for_internal_service
Houliang Qi created IOTDB-5261: -- Summary: The number of clients in client pool of AsyncIoTConsensusServiceClient can not be changed through dn_max_connection_for_internal_service Key: IOTDB-5261 URL: https://issues.apache.org/jira/browse/IOTDB-5261 Project: Apache IoTDB Issue Type: Bug Components: Core/Server Affects Versions: 1.0.0 Reporter: Houliang Qi Attachments: image-2022-12-21-17-16-13-037.png The number of clients in the client pool of AsyncIoTConsensusServiceClient can not be changed through _dn_max_connection_for_internal_service_ we change the _dn_max_connection_for_internal_service_ to 500, however it not take effect. _!image-2022-12-21-17-16-13-037.png!_ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IOTDB-5253) Metrics of the database's memory cost maybe wrong
Houliang Qi created IOTDB-5253: -- Summary: Metrics of the database's memory cost maybe wrong Key: IOTDB-5253 URL: https://issues.apache.org/jira/browse/IOTDB-5253 Project: Apache IoTDB Issue Type: Bug Components: Core/Engine Reporter: Houliang Qi Attachments: image-2022-12-20-18-18-44-332.png, image-2022-12-20-18-19-08-489.png Through the dashboard, we can see that the database's memory cost only occupies 139MB, and the chunk metadata of the database occupies 0 MB. However when we dump the process's memory, only the ChunkMetadata occupies about 3GB. which does not match. !image-2022-12-20-18-18-44-332.png! !image-2022-12-20-18-19-08-489.png! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IOTDB-5105) Can not register new confignode to cluster
Houliang Qi created IOTDB-5105: -- Summary: Can not register new confignode to cluster Key: IOTDB-5105 URL: https://issues.apache.org/jira/browse/IOTDB-5105 Project: Apache IoTDB Issue Type: Bug Components: Core/Cluster Reporter: Houliang Qi Attachments: image-2022-12-01-17-58-05-668.png Hi, I found one bug when registering a new confignode to the cluster. when registering the new confignode to the cluster, the target confignode will check the _least_data_region_group_num_ , however, the parameter can auto-be adjusted in the cluster, which causes the node that wants to register the cluster can not to register successfully. !image-2022-12-01-17-58-05-668.png! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IOTDB-4836) Support multi-tenancy
[ https://issues.apache.org/jira/browse/IOTDB-4836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Houliang Qi reassigned IOTDB-4836: -- Assignee: 任宇华 > Support multi-tenancy > - > > Key: IOTDB-4836 > URL: https://issues.apache.org/jira/browse/IOTDB-4836 > Project: Apache IoTDB > Issue Type: New Feature > Components: Core/Engine >Reporter: Houliang Qi >Assignee: 任宇华 >Priority: Major > > The design and user manual： > https://apache-iotdb.feishu.cn/drive/folder/fldcnM1FWjno8GDkBWXiK4J35Ib -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IOTDB-4836) Support multi-tenancy
Houliang Qi created IOTDB-4836: -- Summary: Support multi-tenancy Key: IOTDB-4836 URL: https://issues.apache.org/jira/browse/IOTDB-4836 Project: Apache IoTDB Issue Type: New Feature Components: Core/Engine Reporter: Houliang Qi The design and user manual： https://apache-iotdb.feishu.cn/drive/folder/fldcnM1FWjno8GDkBWXiK4J35Ib -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IOTDB-3660) stop-datanode.sh/bat should only stop the process of IoTDB
Houliang Qi created IOTDB-3660: -- Summary: stop-datanode.sh/bat should only stop the process of IoTDB Key: IOTDB-3660 URL: https://issues.apache.org/jira/browse/IOTDB-3660 Project: Apache IoTDB Issue Type: New Feature Components: Core/Cluster Reporter: Houliang Qi Fix For: 0.14.0 Now, many other modules process may start as DataNode, for example, Hadoop. which contains DataNode. howere the stop script of the datanode not distinguish which process is IoTDB, which is others. we can refer to the old stop-server.sh for example. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (IOTDB-2716) Support CREATE SNAPSHOT FOR SCHEMA in cluster module
Houliang Qi created IOTDB-2716: -- Summary: Support CREATE SNAPSHOT FOR SCHEMA in cluster module Key: IOTDB-2716 URL: https://issues.apache.org/jira/browse/IOTDB-2716 Project: Apache IoTDB Issue Type: New Feature Components: Core/Cluster Reporter: Houliang Qi In the cluster module, the command *CREATE SNAPSHOT FOR SCHEMA* is not supported. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IOTDB-2175) Cli create wrong timeseries do not as except
[ https://issues.apache.org/jira/browse/IOTDB-2175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17462945#comment-17462945 ] Houliang Qi commented on IOTDB-2175: Yes really weird. > Cli create wrong timeseries do not as except > > > Key: IOTDB-2175 > URL: https://issues.apache.org/jira/browse/IOTDB-2175 > Project: Apache IoTDB > Issue Type: Bug > Components: Core/Engine >Reporter: Houliang Qi >Priority: Minor > Attachments: image-2021-12-17-16-29-08-807.png, > image-2021-12-21-10-25-39-696.png > > > using the following command to create timeseries: > _create timeseries root.ln.wf01. _wt01. _status with > datatype=BOOLEAN,encoding=PLAIN_ > Notice that the _wf01. _wt01. _status_ have one empty string. > It can create succuss, however when we show the timeseries, it do not > contains empty string. > !image-2021-12-17-16-29-08-807.png! -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IOTDB-2175) Cli create wrong timeseries do not as except
[ https://issues.apache.org/jira/browse/IOTDB-2175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17462931#comment-17462931 ] Houliang Qi commented on IOTDB-2175: Yes, actually, IMO, the above timeseries is illegal, so should not be created succssfully... > Cli create wrong timeseries do not as except > > > Key: IOTDB-2175 > URL: https://issues.apache.org/jira/browse/IOTDB-2175 > Project: Apache IoTDB > Issue Type: Bug > Components: Core/Engine >Reporter: Houliang Qi >Priority: Minor > Attachments: image-2021-12-17-16-29-08-807.png > > > using the following command to create timeseries: > _create timeseries root.ln.wf01. _wt01. _status with > datatype=BOOLEAN,encoding=PLAIN_ > Notice that the _wf01. _wt01. _status_ have one empty string. > It can create succuss, however when we show the timeseries, it do not > contains empty string. > !image-2021-12-17-16-29-08-807.png! -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (IOTDB-2171) createTimeseries interface in session can create invalid timeseries
[ https://issues.apache.org/jira/browse/IOTDB-2171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Houliang Qi reassigned IOTDB-2171: -- Assignee: (was: Houliang Qi) > createTimeseries interface in session can create invalid timeseries > --- > > Key: IOTDB-2171 > URL: https://issues.apache.org/jira/browse/IOTDB-2171 > Project: Apache IoTDB > Issue Type: Improvement > Components: Core/Engine >Reporter: Houliang Qi >Priority: Major > Labels: pull-request-available > Attachments: image-2021-12-17-09-41-32-308.png > > > When using _createTimeseries_ interface in session, it can create invalid > timeseries, like the following, it's because the _createTimeseries interface_ > in session do not check the grammer which JDBC or CLI check using antlr. > !image-2021-12-17-09-41-32-308.png! > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IOTDB-2175) Cli create wrong timeseries do not as except
Houliang Qi created IOTDB-2175: -- Summary: Cli create wrong timeseries do not as except Key: IOTDB-2175 URL: https://issues.apache.org/jira/browse/IOTDB-2175 Project: Apache IoTDB Issue Type: Improvement Components: Core/Engine Reporter: Houliang Qi Attachments: image-2021-12-17-16-29-08-807.png using the following command to create timeseries: _create timeseries root.ln.wf01. _wt01. _status with datatype=BOOLEAN,encoding=PLAIN_ Notice that the _wf01. _wt01. _status_ have one empty string. It can create succuss, however when we show the timeseries, it do not contains empty string. !image-2021-12-17-16-29-08-807.png! -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (IOTDB-2171) createTimeseries interface in session can create invalid timeseries
[ https://issues.apache.org/jira/browse/IOTDB-2171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Houliang Qi reassigned IOTDB-2171: -- Assignee: Houliang Qi > createTimeseries interface in session can create invalid timeseries > --- > > Key: IOTDB-2171 > URL: https://issues.apache.org/jira/browse/IOTDB-2171 > Project: Apache IoTDB > Issue Type: Improvement > Components: Core/Engine >Reporter: Houliang Qi >Assignee: Houliang Qi >Priority: Major > Fix For: 0.12.4 > > Attachments: image-2021-12-17-09-41-32-308.png > > > When using _createTimeseries_ interface in session, it can create invalid > timeseries, like the following, it's because the _createTimeseries interface_ > in session do not check the grammer which JDBC or CLI check using antlr. > !image-2021-12-17-09-41-32-308.png! > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IOTDB-2171) createTimeseries interface in session can create invalid timeseries
Houliang Qi created IOTDB-2171: -- Summary: createTimeseries interface in session can create invalid timeseries Key: IOTDB-2171 URL: https://issues.apache.org/jira/browse/IOTDB-2171 Project: Apache IoTDB Issue Type: Improvement Components: Core/Engine Reporter: Houliang Qi Fix For: 0.12.4 Attachments: image-2021-12-17-09-41-32-308.png When using _createTimeseries_ interface in session, it can create invalid timeseries, like the folloing, it's because the _createTimeseries interface_ in session do not check the grammer which JDBC or CLI check using antlr. !image-2021-12-17-09-41-32-308.png! -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (IOTDB-1817) support connect to multi node in go-client
[ https://issues.apache.org/jira/browse/IOTDB-1817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Houliang Qi reassigned IOTDB-1817: -- Assignee: jihang > support connect to multi node in go-client > -- > > Key: IOTDB-1817 > URL: https://issues.apache.org/jira/browse/IOTDB-1817 > Project: Apache IoTDB > Issue Type: New Feature > Components: Client/Others >Reporter: WangChao >Assignee: jihang >Priority: Major > Labels: features > > Now, java client could connect to multi nodes in iotdb cluster, we > couldmigrate the feature to go-client. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IOTDB-1753) NPE when colse when tsfile
Houliang Qi created IOTDB-1753: -- Summary: NPE when colse when tsfile Key: IOTDB-1753 URL: https://issues.apache.org/jira/browse/IOTDB-1753 Project: Apache IoTDB Issue Type: Bug Components: Core/Engine Reporter: Houliang Qi Attachments: image-2021-09-28-15-24-46-518.png Version: 0.12.1 when flush one tsfile, it encountered NPE and caused the whole system to read-only !image-2021-09-28-15-24-46-518.png! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IOTDB-1502) Syncleader optimization
Houliang Qi created IOTDB-1502: -- Summary: Syncleader optimization Key: IOTDB-1502 URL: https://issues.apache.org/jira/browse/IOTDB-1502 Project: Apache IoTDB Issue Type: Improvement Components: Cluster Reporter: Houliang Qi At present, there are many operations of *syncLeader*: they are roughly divided into two categories: 1. Need to synchronize metadata such as storage group; 2. Need to synchronize data; At present, for *syncLeader* operations, the local raft commit index should be consistent with the leader commit index. In fact, it is unnecessary to synchronize metadata. Because this raft log may be a data operation. Due to the storage group has the concept of version, the metadata synchronization operation can be synchronized by the storage group version[1], avoid unnecessary data synchronization and save time. [1] https://issues.apache.org/jira/browse/IOTDB-1292 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IOTDB-1407) Filtering Time Series Based on TAGS Queries Fails Occasionally
[ https://issues.apache.org/jira/browse/IOTDB-1407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Houliang Qi reassigned IOTDB-1407: -- Assignee: Chao Wang (was: Houliang Qi) > Filtering Time Series Based on TAGS Queries Fails Occasionally > -- > > Key: IOTDB-1407 > URL: https://issues.apache.org/jira/browse/IOTDB-1407 > Project: Apache IoTDB > Issue Type: Bug > Components: Cluster >Affects Versions: 0.12.0 >Reporter: Chao Wang >Assignee: Chao Wang >Priority: Major > Labels: pull-request-available > Fix For: 0.12.1 > > > 5 node , 3 rep. > 1. Connect to the client. > 2. Run the show timeseries root.turbine where owner=user1 command. > !https://clouddevops.huawei.com/vision-file-storage/api/file/download/upload-v2/2021/4/17/z00293891/c0cf09e7f81c46cfb742386e05b746d5/image.png! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IOTDB-1452) too many CompactionAllPartitionTask log
[ https://issues.apache.org/jira/browse/IOTDB-1452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17369797#comment-17369797 ] Houliang Qi commented on IOTDB-1452: +1 > too many CompactionAllPartitionTask log > --- > > Key: IOTDB-1452 > URL: https://issues.apache.org/jira/browse/IOTDB-1452 > Project: Apache IoTDB > Issue Type: Bug >Affects Versions: 0.12.1 >Reporter: Xiangdong Huang >Priority: Major > > The log: > o.a.i.d.e.s.StorageGroupProcessor$CompactionAllPartitionTask:522 - all > partition in storage group > is printed every 10 seconds in INFO level, which is no need. > > By the way, what does this log want to show? I do not think the partition > info should be list by CompactionAllPartitionTask... > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IOTDB-1453) cluster/server query time range error message diff
[ https://issues.apache.org/jira/browse/IOTDB-1453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Houliang Qi reassigned IOTDB-1453: -- Assignee: jihang > cluster/server query time range error message diff > --- > > Key: IOTDB-1453 > URL: https://issues.apache.org/jira/browse/IOTDB-1453 > Project: Apache IoTDB > Issue Type: Bug >Reporter: Haimei Guo >Assignee: jihang >Priority: Major > Labels: pull-request-available > Attachments: image-2021-06-24-14-31-44-973.png > > > when query a time range that includes no data point, server and cluster mode > behave differently. Cluster throws an error message, and server returns an > empty result set. The details are shown below. > > sql: > select status, temperature from root.ln.wf01.wt01 where time < > 2017-11-01T00:05:00.000 and time > 2017-11-01T00:12:00.000 > !image-2021-06-24-14-31-44-973.png! > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IOTDB-1399) Make session and jdbc interface more adaptable to the cluster
[ https://issues.apache.org/jira/browse/IOTDB-1399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Houliang Qi reassigned IOTDB-1399: -- Assignee: jihang > Make session and jdbc interface more adaptable to the cluster > - > > Key: IOTDB-1399 > URL: https://issues.apache.org/jira/browse/IOTDB-1399 > Project: Apache IoTDB > Issue Type: Improvement > Components: Client/Java, Cluster >Reporter: Xinyu Tan >Assignee: jihang >Priority: Major > Labels: pull-request-available > Fix For: master branch > > > While the cluster is running, the coordinator node may go down, which may > cause the session/jdbc to be unable to read or write properly. However, it is > possible that most of the nodes in the cluster are running, and a different > coordinator node can work just fine. Therefore, it is necessary to make the > Session/jdbc interface more adaptable to the cluster, including but not > limited to transparent fault tolerance for the business layer and query load > balancing. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IOTDB-1443) Scale specification keyword on docker compuse is deprecated
Houliang Qi created IOTDB-1443: -- Summary: Scale specification keyword on docker compuse is deprecated Key: IOTDB-1443 URL: https://issues.apache.org/jira/browse/IOTDB-1443 Project: Apache IoTDB Issue Type: Improvement Components: Test Reporter: Houliang Qi Attachments: image-2021-06-17-14-29-45-323.png The errors are as follows, and the *scale* specification keyword is deprecated[1], and it suggest using *replicas*[2],so I think we we should change it. [1][https://github.com/compose-spec/compose-spec/blob/master/spec.md#scale] [[2]https://github.com/compose-spec/compose-spec/blob/master/deploy.md#replicas|https://github.com/compose-spec/compose-spec/blob/master/deploy.md#replicas] !image-2021-06-17-14-29-45-323.png! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IOTDB-1437) tsfile sketch tool NPE
[ https://issues.apache.org/jira/browse/IOTDB-1437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Houliang Qi reassigned IOTDB-1437: -- Assignee: Houliang Qi > tsfile sketch tool NPE > -- > > Key: IOTDB-1437 > URL: https://issues.apache.org/jira/browse/IOTDB-1437 > Project: Apache IoTDB > Issue Type: Bug > Components: Core/TsFile >Reporter: Houliang Qi >Assignee: Houliang Qi >Priority: Major > Attachments: image-2021-06-11-15-06-51-086.png > > > !image-2021-06-11-15-06-51-086.png! > > branch： master > commitid：03e920ec5707f32a603410844a99fec5ce03e0c7 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IOTDB-1437) tsfile sketch tool NPE
Houliang Qi created IOTDB-1437: -- Summary: tsfile sketch tool NPE Key: IOTDB-1437 URL: https://issues.apache.org/jira/browse/IOTDB-1437 Project: Apache IoTDB Issue Type: Bug Components: Core/TsFile Reporter: Houliang Qi Attachments: image-2021-06-11-15-06-51-086.png !image-2021-06-11-15-06-51-086.png! branch： master commitid：03e920ec5707f32a603410844a99fec5ce03e0c7 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IOTDB-1368) Support to modify IP and port in cluster mode
[ https://issues.apache.org/jira/browse/IOTDB-1368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17358295#comment-17358295 ] Houliang Qi commented on IOTDB-1368: Thanks [~jihang], please post your design doc here, and we can discuss it before develop. > Support to modify IP and port in cluster mode > - > > Key: IOTDB-1368 > URL: https://issues.apache.org/jira/browse/IOTDB-1368 > Project: Apache IoTDB > Issue Type: New Feature > Components: Core/Cluster >Reporter: Houliang Qi >Assignee: jihang >Priority: Major > > At present, in the cluster mode, when the cluster is successfully created, it > is not allowed to modify the IP and port. However, in some scenarios, > modifying the IP and port exists, and we should support this scenario. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IOTDB-1414) NPE occurred when call getStorageGroupNodeByPath() method using not exist path
Houliang Qi created IOTDB-1414: -- Summary: NPE occurred when call getStorageGroupNodeByPath() method using not exist path Key: IOTDB-1414 URL: https://issues.apache.org/jira/browse/IOTDB-1414 Project: Apache IoTDB Issue Type: Bug Components: Core/Engine Reporter: Houliang Qi Fix For: 0.12.1 Attachments: image-2021-06-02-09-07-41-264.png !image-2021-06-02-09-07-41-264.png! NPE occurred when call getStorageGroupNodeByPath() method using not exist path -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IOTDB-1407) Filtering Time Series Based on TAGS Queries Fails Occasionally
[ https://issues.apache.org/jira/browse/IOTDB-1407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17354323#comment-17354323 ] Houliang Qi commented on IOTDB-1407: Hi, It seems that this image is linked to your intranet. It can't be displayed here > Filtering Time Series Based on TAGS Queries Fails Occasionally > -- > > Key: IOTDB-1407 > URL: https://issues.apache.org/jira/browse/IOTDB-1407 > Project: Apache IoTDB > Issue Type: Bug > Components: Cluster >Affects Versions: 0.12.0 >Reporter: Chao Wang >Assignee: Houliang Qi >Priority: Major > Labels: pull-request-available > Fix For: 0.12.1 > > > 5 node , 3 rep. > 1. Connect to the client. > 2. Run the show timeseries root.turbine where owner=user1 command. > !https://clouddevops.huawei.com/vision-file-storage/api/file/download/upload-v2/2021/4/17/z00293891/c0cf09e7f81c46cfb742386e05b746d5/image.png! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IOTDB-1407) Filtering Time Series Based on TAGS Queries Fails Occasionally
[ https://issues.apache.org/jira/browse/IOTDB-1407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Houliang Qi reassigned IOTDB-1407: -- Assignee: Houliang Qi (was: Chao Wang) > Filtering Time Series Based on TAGS Queries Fails Occasionally > -- > > Key: IOTDB-1407 > URL: https://issues.apache.org/jira/browse/IOTDB-1407 > Project: Apache IoTDB > Issue Type: Bug > Components: Cluster >Affects Versions: 0.12.0 >Reporter: Chao Wang >Assignee: Houliang Qi >Priority: Major > Labels: pull-request-available > Fix For: 0.12.1 > > > 5 node , 3 rep. > 1. Connect to the client. > 2. Run the show timeseries root.turbine where owner=user1 command. > !https://clouddevops.huawei.com/vision-file-storage/api/file/download/upload-v2/2021/4/17/z00293891/c0cf09e7f81c46cfb742386e05b746d5/image.png! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IOTDB-1292) Differentiable MTree
[ https://issues.apache.org/jira/browse/IOTDB-1292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Houliang Qi reassigned IOTDB-1292: -- Assignee: Houliang Qi > Differentiable MTree > > > Key: IOTDB-1292 > URL: https://issues.apache.org/jira/browse/IOTDB-1292 > Project: Apache IoTDB > Issue Type: Improvement > Components: Core/Cluster >Reporter: Tian Jiang >Assignee: Houliang Qi >Priority: Major > Labels: metadata, synchronization > > We have the sync tool for incremental data file synchronization, but it is > non-trivial to synchronize metadata incrementally since two MTrees cannot be > compared at a low cost. > So differentiable MTree is necessary to make it possible to compare two > MTrees and find the difference between them. When synchronizing the metadata, > only the difference will be transmitted and thus the bandwidth usage is > reduced. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IOTDB-1381) Aligned timeseries feature of the cluster module is not OK
Houliang Qi created IOTDB-1381: -- Summary: Aligned timeseries feature of the cluster module is not OK Key: IOTDB-1381 URL: https://issues.apache.org/jira/browse/IOTDB-1381 Project: Apache IoTDB Issue Type: Bug Components: Cluster Reporter: Houliang Qi Attachments: image-2021-05-18-11-00-41-187.png !image-2021-05-18-11-00-41-187.png! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IOTDB-1375) Some docs of cluster setup are outdated (Version 0.12)
[ https://issues.apache.org/jira/browse/IOTDB-1375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Houliang Qi reassigned IOTDB-1375: -- Assignee: Houliang Qi > Some docs of cluster setup are outdated (Version 0.12) > --- > > Key: IOTDB-1375 > URL: https://issues.apache.org/jira/browse/IOTDB-1375 > Project: Apache IoTDB > Issue Type: Bug > Components: Cluster >Reporter: Houliang Qi >Assignee: Houliang Qi >Priority: Major > Fix For: 0.12.1 > > > Some contents of the docs are out of date, we need to upgrade it. > http://iotdb.apache.org/zh/UserGuide/V0.12.x/QuickStart/QuickStart.html -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IOTDB-1375) Cluster doc is old
Houliang Qi created IOTDB-1375: -- Summary: Cluster doc is old Key: IOTDB-1375 URL: https://issues.apache.org/jira/browse/IOTDB-1375 Project: Apache IoTDB Issue Type: Bug Components: Cluster Reporter: Houliang Qi Fix For: 0.12.1 Some contents of the docs are out of date, we need to upgrade it. http://iotdb.apache.org/zh/UserGuide/V0.12.x/QuickStart/QuickStart.html -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IOTDB-1368) Support to modify IP and port in cluster mode
Houliang Qi created IOTDB-1368: -- Summary: Support to modify IP and port in cluster mode Key: IOTDB-1368 URL: https://issues.apache.org/jira/browse/IOTDB-1368 Project: Apache IoTDB Issue Type: New Feature Components: Core/Cluster Reporter: Houliang Qi At present, in the cluster mode, when the cluster is successfully created, it is not allowed to modify the IP and port. However, in some scenarios, modifying the IP and port exists, and we should support this scenario. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IOTDB-1341) Print too many useless logs when snapshot occurred loading one tsfile
Houliang Qi created IOTDB-1341: -- Summary: Print too many useless logs when snapshot occurred loading one tsfile Key: IOTDB-1341 URL: https://issues.apache.org/jira/browse/IOTDB-1341 Project: Apache IoTDB Issue Type: Improvement Components: Core/Engine Reporter: Houliang Qi Attachments: image-2021-04-29-10-10-15-318.png, image-2021-04-29-10-10-37-566.png When one tsfile have so many timeseries, and when snapshot occurred loading one tsfile, every timeseries will print one log as follows, it consumes many disk IO, I think we can change it to debug level. !image-2021-04-29-10-10-15-318.png! !image-2021-04-29-10-10-37-566.png! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IOTDB-1341) Print too many useless logs when snapshot occurred loading one tsfile
[ https://issues.apache.org/jira/browse/IOTDB-1341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Houliang Qi reassigned IOTDB-1341: -- Assignee: Houliang Qi > Print too many useless logs when snapshot occurred loading one tsfile > - > > Key: IOTDB-1341 > URL: https://issues.apache.org/jira/browse/IOTDB-1341 > Project: Apache IoTDB > Issue Type: Improvement > Components: Core/Engine >Reporter: Houliang Qi >Assignee: Houliang Qi >Priority: Major > Attachments: image-2021-04-29-10-10-15-318.png, > image-2021-04-29-10-10-37-566.png > > > When one tsfile have so many timeseries, and when snapshot occurred loading > one tsfile, every timeseries will print one log as follows, it consumes many > disk IO, I think we can change it to debug level. > !image-2021-04-29-10-10-15-318.png! > !image-2021-04-29-10-10-37-566.png! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IOTDB-1330) After loading the TsFile file，reported an error In a clean server
[ https://issues.apache.org/jira/browse/IOTDB-1330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Houliang Qi reassigned IOTDB-1330: -- Assignee: Houliang Qi > After loading the TsFile file，reported an error In a clean server > -- > > Key: IOTDB-1330 > URL: https://issues.apache.org/jira/browse/IOTDB-1330 > Project: Apache IoTDB > Issue Type: Bug > Components: Server >Affects Versions: 0.12.0 >Reporter: xiaozhihong >Assignee: Houliang Qi >Priority: Major > > step 1： > No partition,write data by benchmark, and enter cli, then query data, > finally flush. > step 2: > Backup the generated TsFile file to new route > step 3: > Start a clean server, open the partition > step4: > Enter cli, load the TsFile > Actually，load failed > load "/home/xzh/0.12.0/load_TsFile/1619502355580-1-0-0.tsfile" true > Msg: 411: Cannot load file > /home/xzh/0.12.0/load_TsFile/1619502355580-1-0-0.tsfile because null > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IOTDB-1138) Compaction encountered some errors
[ https://issues.apache.org/jira/browse/IOTDB-1138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17331795#comment-17331795 ] Houliang Qi commented on IOTDB-1138: The following PR resolves the issue. [https://github.com/apache/iotdb/pull/2811] > Compaction encountered some errors > -- > > Key: IOTDB-1138 > URL: https://issues.apache.org/jira/browse/IOTDB-1138 > Project: Apache IoTDB > Issue Type: Bug > Components: Core/Engine >Reporter: Houliang Qi >Priority: Major > Labels: pull-request-available > Attachments: image-2021-01-29-17-23-53-280.png > > > When using iotdb-benchmark to write continuously, some merge errors will be > reported in the log as follows: > !image-2021-01-29-17-23-53-280.png! > besides, there are some bugs that are introduced by merge, for example: > > [https://github.com/apache/iotdb/issues/2549] > [https://github.com/apache/iotdb/issues/2545] > [https://github.com/apache/iotdb/pulls?q=is%3Apr+merge+is%3Aclosed] > > We are very happy to see the introduction of merge in version 0.11, but we > are also a little worried about whether merge can really be applied in the > production environment? > Whether it is necessary to add a lot of tests specifically for merge？ -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IOTDB-1299) Concurrent problems caused by concurrent modification of metadata by MetaRaftGroup and DataRaftGroup
[ https://issues.apache.org/jira/browse/IOTDB-1299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Houliang Qi reassigned IOTDB-1299: -- Assignee: Houliang Qi > Concurrent problems caused by concurrent modification of metadata by > MetaRaftGroup and DataRaftGroup > > > Key: IOTDB-1299 > URL: https://issues.apache.org/jira/browse/IOTDB-1299 > Project: Apache IoTDB > Issue Type: Bug > Components: Core/Cluster >Reporter: Haimei Guo >Assignee: Houliang Qi >Priority: Major > Attachments: image-2021-04-13-17-24-23-425.png > > > in cluster mode, when executing CREATE right after DELETE, it failed and > showed "storage group not set" error. > # storage group root.ln exists; > # delete storage group root.ln > # create timeseries under root.ln failed > SQL as following: > * sbin/start-cli.sh -h 172.16.48.4 -p 55890 -e "set storage group to > root.ln; show storage group; delete storage group root.ln; create timeseries > root.ln.wf01.wt01.temperature with datatype=INT32,encoding=PLAIN;" > !image-2021-04-13-17-24-23-425.png! > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IOTDB-1248) The two raft groups wait from each other until syncLeader timeout when time partition enabled
[ https://issues.apache.org/jira/browse/IOTDB-1248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17331703#comment-17331703 ] Houliang Qi commented on IOTDB-1248: I will close the issue as it has been resolved. > The two raft groups wait from each other until syncLeader timeout when time > partition enabled > -- > > Key: IOTDB-1248 > URL: https://issues.apache.org/jira/browse/IOTDB-1248 > Project: Apache IoTDB > Issue Type: Bug > Components: Cluster >Reporter: Houliang Qi >Assignee: Chao Wang >Priority: Major > Labels: pull-request-available > Fix For: 0.12.0 > > > For details, please see: > https://shimo.im/docs/wJVKTvKcyJRhGQvg/ -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IOTDB-1268) correct cluster to iotdb-cluster when pacakging zip files
[ https://issues.apache.org/jira/browse/IOTDB-1268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Houliang Qi reassigned IOTDB-1268: -- Assignee: Houliang Qi > correct cluster to iotdb-cluster when pacakging zip files > - > > Key: IOTDB-1268 > URL: https://issues.apache.org/jira/browse/IOTDB-1268 > Project: Apache IoTDB > Issue Type: Bug >Reporter: Houliang Qi >Assignee: Houliang Qi >Priority: Major > Labels: pull-request-available > Attachments: image-2021-03-31-16-14-10-290.png > > > The apache-iotdb-0.12.0-SNAPSHOT-all-bin package forget packaging the > iotdb-cluster.properties confiration file. > > commit id : 2e7a32ed9cc761b2f497397638297dfba46cda6b > !image-2021-03-31-16-14-10-290.png! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IOTDB-1269) print-tsfile-sketch tool throw exception when prase one tsfile
[ https://issues.apache.org/jira/browse/IOTDB-1269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17331702#comment-17331702 ] Houliang Qi commented on IOTDB-1269: Hi, [~ericpai] any updates about this issue? > print-tsfile-sketch tool throw exception when prase one tsfile > --- > > Key: IOTDB-1269 > URL: https://issues.apache.org/jira/browse/IOTDB-1269 > Project: Apache IoTDB > Issue Type: Bug >Reporter: Houliang Qi >Assignee: Eric Pai >Priority: Major > Attachments: image-2021-03-31-16-35-33-396.png > > > version 0.12-snapshot（master） > commid id : 2e7a32ed9cc761b2f497397638297dfba46cda6b > > use benchmark insert some records and execute the flush command, then use > print-tsfile-sketch.sh tool to prase the tsfile, it will produce the > following error. > !image-2021-03-31-16-35-33-396.png! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IOTDB-1317) [Cluster] Log CatchUp always failed du to not check the follower's match index
[ https://issues.apache.org/jira/browse/IOTDB-1317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Houliang Qi reassigned IOTDB-1317: -- Assignee: Houliang Qi > [Cluster] Log CatchUp always failed du to not check the follower's match index > -- > > Key: IOTDB-1317 > URL: https://issues.apache.org/jira/browse/IOTDB-1317 > Project: Apache IoTDB > Issue Type: Bug > Components: Cluster >Reporter: Houliang Qi >Assignee: Houliang Qi >Priority: Major > Fix For: 0.12.1 > > > When the follower lags behind the leader, it will catch up with the leader > through the log. When it can't find the logs to catch up with in the memory > of the leader, it will go to the file on the local disk to find the satisfied > logs. The logs found are between the *old match index* and the *commit index* > saved by the leader. However, at this time, the match index of the follower > may have been updated and the *old match index* of the follower may have been > deleted (in order to prevent a large number of logs from being kept on disk, > there is a log deletion mechanism). So at this time, if you send the above > logs to the follower, the follower will fail to find the matching log. At > this time, this storage group will appear to write stuck phenomenon. > The solution is to re-check the match index of the follower after reading the > log from the disk. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IOTDB-1317) [Cluster] Log CatchUp always failed du to not check the follower's match index
Houliang Qi created IOTDB-1317: -- Summary: [Cluster] Log CatchUp always failed du to not check the follower's match index Key: IOTDB-1317 URL: https://issues.apache.org/jira/browse/IOTDB-1317 Project: Apache IoTDB Issue Type: Bug Components: Cluster Reporter: Houliang Qi Fix For: 0.12.1 When the follower lags behind the leader, it will catch up with the leader through the log. When it can't find the log to catch up with in the memory of the leader, it will go to the file on the local disk to find the satisfied log. The logs found are between the *old match index* and the *commit index* saved by the leader. However, at this time, the match index of the follower may have been updated and the *old match index* of the follower may have been deleted (in order to prevent a large number of logs from being kept on disk, there is a log deletion mechanism). So at this time, if you send the above logs to the follower, the follower will fail to find the matching log. At this time, this storage group will appear to write stuck phenomenon. The solution is to re-check the match index of the follower after reading the log from the disk. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IOTDB-1292) Differentiable MTree
[ https://issues.apache.org/jira/browse/IOTDB-1292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17317565#comment-17317565 ] Houliang Qi commented on IOTDB-1292: +1, It is expected to improve the performance greatly > Differentiable MTree > > > Key: IOTDB-1292 > URL: https://issues.apache.org/jira/browse/IOTDB-1292 > Project: Apache IoTDB > Issue Type: Improvement > Components: Core/Cluster >Reporter: Tian Jiang >Priority: Major > Labels: metadata, synchronization > > We have the sync tool for incremental data file synchronization, but it is > non-trivial to synchronize metadata incrementally since two MTrees cannot be > compared at a low cost. > So differentiable MTree is necessary to make it possible to compare two > MTrees and find the difference between them. When synchronizing the metadata, > only the difference will be transmitted and thus the bandwidth usage is > reduced. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IOTDB-1269) print-tsfile-sketch tool throw exception when prase one tsfile
Houliang Qi created IOTDB-1269: -- Summary: print-tsfile-sketch tool throw exception when prase one tsfile Key: IOTDB-1269 URL: https://issues.apache.org/jira/browse/IOTDB-1269 Project: Apache IoTDB Issue Type: Bug Reporter: Houliang Qi Attachments: image-2021-03-31-16-35-33-396.png version 0.12-snapshot（master） commid id : 2e7a32ed9cc761b2f497397638297dfba46cda6b use benchmark insert some records and execute the flush command, then use print-tsfile-sketch.sh tool to prase the tsfile, it will produce the following error. !image-2021-03-31-16-35-33-396.png! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IOTDB-1268) correct cluster to iotdb-cluster when pacakging zip files
Houliang Qi created IOTDB-1268: -- Summary: correct cluster to iotdb-cluster when pacakging zip files Key: IOTDB-1268 URL: https://issues.apache.org/jira/browse/IOTDB-1268 Project: Apache IoTDB Issue Type: Bug Reporter: Houliang Qi Attachments: image-2021-03-31-16-14-10-290.png The apache-iotdb-0.12.0-SNAPSHOT-all-bin package forget packaging the iotdb-cluster.properties confiration file. commit id : 2e7a32ed9cc761b2f497397638297dfba46cda6b !image-2021-03-31-16-14-10-290.png! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IOTDB-1209) When loading a tsfile with a large timestamp, the data is incorrect
[ https://issues.apache.org/jira/browse/IOTDB-1209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17312113#comment-17312113 ] Houliang Qi commented on IOTDB-1209: Hi, [~ericpai], the picture you post can not be seen. The tsfile is created by the iotdb-benchmark, but I think you can just write the records as the above Step2 shows and then execute the flush command, you will get one new tsfile and clean all the data and reproduce the error. > When loading a tsfile with a large timestamp, the data is incorrect > --- > > Key: IOTDB-1209 > URL: https://issues.apache.org/jira/browse/IOTDB-1209 > Project: Apache IoTDB > Issue Type: Bug >Affects Versions: 0.11.2 >Reporter: Houliang Qi >Assignee: Eric Pai >Priority: Critical > Attachments: 1.1.png, 1.2.png, 1.3.png, 1.4.png, 1.5.png, > 1678502448000-1-0.tsfile > > > Step 1： > # insert into root.group_1.d_1(timestamp, s_1, s_0, s_2) > values(2018-07-18T00:00:00.000+08:00, 18, false, 18.18) > # flush > # insert into root.group_1.d_1(timestamp, s_1, s_0, s_2) > values(2018-07-19T00:00:00.000+08:00, 19, false, 19.18) > # flush > !1.1.png! > > Step2： > load one tsfile which the tsfile name have a large timestamp, but its data's > timestamp are small. > # load "../1678502448000-1-0.tsfile" > # !1.2.png! > # after load the tsfile, we can see that the root.group_1.d_1 has 3 rows as > below. > # !1.3.png! > > Step3：insert another two rows > # insert into root.group_1.d_1(timestamp, s_1, s_0, s_2) > values(2019-07-19T00:00:00.000+08:00, 2019, false, 19.18) > # insert into root.group_1.d_1(timestamp, s_1, s_0, s_2) > values(2019-08-19T00:00:00.000+08:00, 2018, false, 19.18) > # we can see that the query result is rowng when we query the > root.group_1.d_1 > !1.4.png! > > Step4 : Query with the order by time keyword, we can see from the result that > it have two problems: > # it's not ordered by time > # time value of time 2018-07-18T00:00:00.000+08:00 （s1, s_0, s2）are (18, > false, 18.18 ) which we insert in step one, however, the result show is > another vlaue. > !1.5.png! > > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IOTDB-1248) The two raft groups wait from each other until syncLeader timeout when time partition enabled
Houliang Qi created IOTDB-1248: -- Summary: The two raft groups wait from each other until syncLeader timeout when time partition enabled Key: IOTDB-1248 URL: https://issues.apache.org/jira/browse/IOTDB-1248 Project: Apache IoTDB Issue Type: Bug Components: Cluster Reporter: Houliang Qi For details, please see: https://shimo.im/docs/wJVKTvKcyJRhGQvg/ -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IOTDB-1230) Load TsFile command do not support the tsfile cross time partition
[ https://issues.apache.org/jira/browse/IOTDB-1230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Houliang Qi reassigned IOTDB-1230: -- Assignee: Houliang Qi > Load TsFile command do not support the tsfile cross time partition > -- > > Key: IOTDB-1230 > URL: https://issues.apache.org/jira/browse/IOTDB-1230 > Project: Apache IoTDB > Issue Type: Improvement > Components: Core/Engine >Reporter: Houliang Qi >Assignee: Houliang Qi >Priority: Major > > Now, when loading one tsfile, if the tsfile crosses multiple time partition, > it can not be loaded. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IOTDB-1230) Load TsFile command do not support the tsfile cross time partition
[ https://issues.apache.org/jira/browse/IOTDB-1230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17303257#comment-17303257 ] Houliang Qi commented on IOTDB-1230: Sure, and I think we need to support this feature, when one tsfile cross multiple time partition, the tsfile can be correctly split according to the time partition interval, these are transparent to users. And I want to have a try to do this issue. > Load TsFile command do not support the tsfile cross time partition > -- > > Key: IOTDB-1230 > URL: https://issues.apache.org/jira/browse/IOTDB-1230 > Project: Apache IoTDB > Issue Type: Improvement > Components: Core/Engine >Reporter: Houliang Qi >Priority: Major > > Now, when loading one tsfile, if the tsfile crosses multiple time partition, > it can not be loaded. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IOTDB-1231) After load tsfile，this tsfile is rudely moved out of its location.
[ https://issues.apache.org/jira/browse/IOTDB-1231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17301361#comment-17301361 ] Houliang Qi commented on IOTDB-1231: +1 I think we can copy the tsfile rather than just move the tsfile to iotdb. > After load tsfile，this tsfile is rudely moved out of its location. > --- > > Key: IOTDB-1231 > URL: https://issues.apache.org/jira/browse/IOTDB-1231 > Project: Apache IoTDB > Issue Type: Bug >Reporter: 刘珍 >Priority: Minor > > master branch. > commit id :5fcff40f2299caeb0c8a9ae42f68bc18ecf8fee7 > > As title，the tsfile is users' *PRIVATE file* ,shouldn't be moved to another > location without permission. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IOTDB-1230) Load TsFile command do not support the tsfile cross time partition
Houliang Qi created IOTDB-1230: -- Summary: Load TsFile command do not support the tsfile cross time partition Key: IOTDB-1230 URL: https://issues.apache.org/jira/browse/IOTDB-1230 Project: Apache IoTDB Issue Type: Improvement Components: Core/Engine Reporter: Houliang Qi Now, when loading one tsfile, if the tsfile crosses multiple time partition, it can not be loaded. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IOTDB-1122) Disable the pre-start customizations debug message
[ https://issues.apache.org/jira/browse/IOTDB-1122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Houliang Qi reassigned IOTDB-1122: -- Assignee: Houliang Qi > Disable the pre-start customizations debug message > --- > > Key: IOTDB-1122 > URL: https://issues.apache.org/jira/browse/IOTDB-1122 > Project: Apache IoTDB > Issue Type: Improvement > Components: Cluster >Reporter: Houliang Qi >Assignee: Houliang Qi >Priority: Major > Labels: pull-request-available > > Now, the distributed version of iotdb have its own data partition strategy, > however, when start the iotdb, there have pre-start customizations codes, > which is debug for tester, which should be comment out when releasing the the > official version. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IOTDB-1208) [master-0.12.0-snapshot][iotdb-cluster]Cannot open transport for client Node
[ https://issues.apache.org/jira/browse/IOTDB-1208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17300132#comment-17300132 ] Houliang Qi commented on IOTDB-1208: I'll close the issue as this have been fixed in PR [https://github.com/apache/iotdb/pull/2807] > [master-0.12.0-snapshot][iotdb-cluster]Cannot open transport for client Node > > > Key: IOTDB-1208 > URL: https://issues.apache.org/jira/browse/IOTDB-1208 > Project: Apache IoTDB > Issue Type: Bug > Components: Cluster >Reporter: FengQingxin >Assignee: Houliang Qi >Priority: Major > Labels: pull-request-available > Attachments: image-2021-03-11-11-02-27-954.png, > image-2021-03-11-11-02-36-333.png, log_all.log > > > branch : master > commit 19ad435bc93c1ae8b71be1e9454bc4dad31018c6 > Author: wangchao316 > <66939405+wangchao316@[users.noreply.github.com|http://users.noreply.github.com/]> > Date: Thu Mar 11 09:01:06 2021 +0800 > [IOTDB-1204] set parameter in iotdb-cluster.properties (#2797) > Repeat steps： > # 第一步 (注意以下路径在 Windows MinGW 中并不适用) > > mvn clean package -pl cluster -am -Dmaven.test.skip=true > > cp -rf ./cluster/target/cluster-0.12.0-SNAPSHOT > ./cluster/target/cluster-0.12.0-SNAPSHOT1 > > cp -rf ./cluster/target/cluster-0.12.0-SNAPSHOT > ./cluster/target/cluster-0.12.0-SNAPSHOT2 > > sed -i -e 's/6667/6668/g' > ./cluster/target/cluster-0.12.0-SNAPSHOT1/conf/iotdb-engine.properties > > sed -i -e 's/6667/6669/g' > ./cluster/target/cluster-0.12.0-SNAPSHOT2/conf/iotdb-engine.properties > # 第二步: Unix/OS X/Windows (git bash or WSL) > > sed -i -e 's/31999/32000/g' > ./cluster/target/cluster-0.12.0-SNAPSHOT1/conf/iotdb-env.sh > > sed -i -e 's/31999/32001/g' > ./cluster/target/cluster-0.12.0-SNAPSHOT2/conf/iotdb-env.sh > > chmod -R 777 ./cluster/target/ > > nohup ./cluster/target/cluster-0.12.0-SNAPSHOT/sbin/start-node.sh > >/dev/null 2>&1 & > > nohup ./cluster/target/cluster-0.12.0-SNAPSHOT1/sbin/start-node.sh > -internal_meta_port 9005 -internal_data_port 40012 -cluster_rpc_port 55561 > >/dev/null 2>&1 & > > nohup ./cluster/target/cluster-0.12.0-SNAPSHOT2/sbin/start-node.sh > -internal_meta_port 9007 -internal_data_port 40014 -cluster_rpc_port 55562 > >/dev/null 2>&1 & > After that I can't connect iotdb with iotdb-cli,and there are error logs in > log_all.log. > Please refer to the attachment. > !image-2021-03-11-11-02-27-954.png!!image-2021-03-11-11-02-36-333.png! > # -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IOTDB-1218) System properties is not persist in cluster version
[ https://issues.apache.org/jira/browse/IOTDB-1218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Houliang Qi reassigned IOTDB-1218: -- Assignee: Houliang Qi > System properties is not persist in cluster version > --- > > Key: IOTDB-1218 > URL: https://issues.apache.org/jira/browse/IOTDB-1218 > Project: Apache IoTDB > Issue Type: Bug >Reporter: Houliang Qi >Assignee: Houliang Qi >Priority: Major > Fix For: 0.12.0 > > > In the single-server mode, when we start one IoTDB instance, we can see that > the file _data/system/schema/system.properties_ contains some system > properties, however, when we set up the cluster, the file is lost. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IOTDB-1218) System properties is not persist in cluster version
Houliang Qi created IOTDB-1218: -- Summary: System properties is not persist in cluster version Key: IOTDB-1218 URL: https://issues.apache.org/jira/browse/IOTDB-1218 Project: Apache IoTDB Issue Type: Bug Reporter: Houliang Qi In the single-server mode, when we start one IoTDB instance, we can see that the file _data/system/schema/system.properties_ contains some system properties, however, when we set up the cluster, the file is lost. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IOTDB-1208) [master-0.12.0-snapshot][iotdb-cluster]Cannot open transport for client Node
[ https://issues.apache.org/jira/browse/IOTDB-1208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Houliang Qi reassigned IOTDB-1208: -- Assignee: Houliang Qi > [master-0.12.0-snapshot][iotdb-cluster]Cannot open transport for client Node > > > Key: IOTDB-1208 > URL: https://issues.apache.org/jira/browse/IOTDB-1208 > Project: Apache IoTDB > Issue Type: Bug > Components: Cluster >Reporter: FengQingxin >Assignee: Houliang Qi >Priority: Major > Labels: pull-request-available > Attachments: image-2021-03-11-11-02-27-954.png, > image-2021-03-11-11-02-36-333.png, log_all.log > > > branch : master > commit 19ad435bc93c1ae8b71be1e9454bc4dad31018c6 > Author: wangchao316 > <66939405+wangchao316@[users.noreply.github.com|http://users.noreply.github.com/]> > Date: Thu Mar 11 09:01:06 2021 +0800 > [IOTDB-1204] set parameter in iotdb-cluster.properties (#2797) > Repeat steps： > # 第一步 (注意以下路径在 Windows MinGW 中并不适用) > > mvn clean package -pl cluster -am -Dmaven.test.skip=true > > cp -rf ./cluster/target/cluster-0.12.0-SNAPSHOT > ./cluster/target/cluster-0.12.0-SNAPSHOT1 > > cp -rf ./cluster/target/cluster-0.12.0-SNAPSHOT > ./cluster/target/cluster-0.12.0-SNAPSHOT2 > > sed -i -e 's/6667/6668/g' > ./cluster/target/cluster-0.12.0-SNAPSHOT1/conf/iotdb-engine.properties > > sed -i -e 's/6667/6669/g' > ./cluster/target/cluster-0.12.0-SNAPSHOT2/conf/iotdb-engine.properties > # 第二步: Unix/OS X/Windows (git bash or WSL) > > sed -i -e 's/31999/32000/g' > ./cluster/target/cluster-0.12.0-SNAPSHOT1/conf/iotdb-env.sh > > sed -i -e 's/31999/32001/g' > ./cluster/target/cluster-0.12.0-SNAPSHOT2/conf/iotdb-env.sh > > chmod -R 777 ./cluster/target/ > > nohup ./cluster/target/cluster-0.12.0-SNAPSHOT/sbin/start-node.sh > >/dev/null 2>&1 & > > nohup ./cluster/target/cluster-0.12.0-SNAPSHOT1/sbin/start-node.sh > -internal_meta_port 9005 -internal_data_port 40012 -cluster_rpc_port 55561 > >/dev/null 2>&1 & > > nohup ./cluster/target/cluster-0.12.0-SNAPSHOT2/sbin/start-node.sh > -internal_meta_port 9007 -internal_data_port 40014 -cluster_rpc_port 55562 > >/dev/null 2>&1 & > After that I can't connect iotdb with iotdb-cli,and there are error logs in > log_all.log. > Please refer to the attachment. > !image-2021-03-11-11-02-27-954.png!!image-2021-03-11-11-02-36-333.png! > # -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IOTDB-1208) [master-0.12.0-snapshot][iotdb-cluster]Cannot open transport for client Node
[ https://issues.apache.org/jira/browse/IOTDB-1208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17299355#comment-17299355 ] Houliang Qi commented on IOTDB-1208: Thank you for your feedback, I will revise the docs description! > [master-0.12.0-snapshot][iotdb-cluster]Cannot open transport for client Node > > > Key: IOTDB-1208 > URL: https://issues.apache.org/jira/browse/IOTDB-1208 > Project: Apache IoTDB > Issue Type: Bug > Components: Cluster >Reporter: FengQingxin >Priority: Major > Attachments: image-2021-03-11-11-02-27-954.png, > image-2021-03-11-11-02-36-333.png, log_all.log > > > branch : master > commit 19ad435bc93c1ae8b71be1e9454bc4dad31018c6 > Author: wangchao316 > <66939405+wangchao316@[users.noreply.github.com|http://users.noreply.github.com/]> > Date: Thu Mar 11 09:01:06 2021 +0800 > [IOTDB-1204] set parameter in iotdb-cluster.properties (#2797) > Repeat steps： > # 第一步 (注意以下路径在 Windows MinGW 中并不适用) > > mvn clean package -pl cluster -am -Dmaven.test.skip=true > > cp -rf ./cluster/target/cluster-0.12.0-SNAPSHOT > ./cluster/target/cluster-0.12.0-SNAPSHOT1 > > cp -rf ./cluster/target/cluster-0.12.0-SNAPSHOT > ./cluster/target/cluster-0.12.0-SNAPSHOT2 > > sed -i -e 's/6667/6668/g' > ./cluster/target/cluster-0.12.0-SNAPSHOT1/conf/iotdb-engine.properties > > sed -i -e 's/6667/6669/g' > ./cluster/target/cluster-0.12.0-SNAPSHOT2/conf/iotdb-engine.properties > # 第二步: Unix/OS X/Windows (git bash or WSL) > > sed -i -e 's/31999/32000/g' > ./cluster/target/cluster-0.12.0-SNAPSHOT1/conf/iotdb-env.sh > > sed -i -e 's/31999/32001/g' > ./cluster/target/cluster-0.12.0-SNAPSHOT2/conf/iotdb-env.sh > > chmod -R 777 ./cluster/target/ > > nohup ./cluster/target/cluster-0.12.0-SNAPSHOT/sbin/start-node.sh > >/dev/null 2>&1 & > > nohup ./cluster/target/cluster-0.12.0-SNAPSHOT1/sbin/start-node.sh > -internal_meta_port 9005 -internal_data_port 40012 -cluster_rpc_port 55561 > >/dev/null 2>&1 & > > nohup ./cluster/target/cluster-0.12.0-SNAPSHOT2/sbin/start-node.sh > -internal_meta_port 9007 -internal_data_port 40014 -cluster_rpc_port 55562 > >/dev/null 2>&1 & > After that I can't connect iotdb with iotdb-cli,and there are error logs in > log_all.log. > Please refer to the attachment. > !image-2021-03-11-11-02-27-954.png!!image-2021-03-11-11-02-36-333.png! > # -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IOTDB-1209) When loading a tsfile with a large timestamp, the data is incorrect
Houliang Qi created IOTDB-1209: -- Summary: When loading a tsfile with a large timestamp, the data is incorrect Key: IOTDB-1209 URL: https://issues.apache.org/jira/browse/IOTDB-1209 Project: Apache IoTDB Issue Type: Bug Reporter: Houliang Qi Step 1： # insert into root.group_1.d_1(timestamp, s_1, s_0, s_2) values(2018-07-18T00:00:00.000+08:00, 18, false, 18.18) # flush # insert into root.group_1.d_1(timestamp, s_1, s_0, s_2) values(2018-07-19T00:00:00.000+08:00, 19, false, 19.18) # flush !https://code.bonc.com.cn/confluence/download/attachments/64011154/image2021-3-11%2012%3A0%3A42.png?version=1=1615435242446=v2! Step2： load one tsfile which the tsfile name have a large timestamp, but its data's timestamp are small. # load "../1678502448000-1-0.tsfile" # !https://code.bonc.com.cn/confluence/download/attachments/64011154/image2021-3-11%2012%3A1%3A12.png?version=1=1615435272389=v2! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IOTDB-1208) [master-0.12.0-snapshot][iotdb-cluster]Cannot open transport for client Node
[ https://issues.apache.org/jira/browse/IOTDB-1208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17299282#comment-17299282 ] Houliang Qi commented on IOTDB-1208: Thanks [~QX.Feng]， I think you referenced the old docs, it have been changed after PR[1], the new setup docs can be found here[2]. You can retry according to [2]. [1]https://github.com/apache/iotdb/pull/2740 [2] http://iotdb.apache.org/UserGuide/Master/Server/Cluster%20Setup.html > [master-0.12.0-snapshot][iotdb-cluster]Cannot open transport for client Node > > > Key: IOTDB-1208 > URL: https://issues.apache.org/jira/browse/IOTDB-1208 > Project: Apache IoTDB > Issue Type: Bug > Components: Cluster >Reporter: FengQingxin >Priority: Major > Attachments: image-2021-03-11-11-02-27-954.png, > image-2021-03-11-11-02-36-333.png, log_all.log > > > branch : master > commit 19ad435bc93c1ae8b71be1e9454bc4dad31018c6 > Author: wangchao316 > <66939405+wangchao316@[users.noreply.github.com|http://users.noreply.github.com/]> > Date: Thu Mar 11 09:01:06 2021 +0800 > [IOTDB-1204] set parameter in iotdb-cluster.properties (#2797) > Repeat steps： > # 第一步 (注意以下路径在 Windows MinGW 中并不适用) > > mvn clean package -pl cluster -am -Dmaven.test.skip=true > > cp -rf ./cluster/target/cluster-0.12.0-SNAPSHOT > ./cluster/target/cluster-0.12.0-SNAPSHOT1 > > cp -rf ./cluster/target/cluster-0.12.0-SNAPSHOT > ./cluster/target/cluster-0.12.0-SNAPSHOT2 > > sed -i -e 's/6667/6668/g' > ./cluster/target/cluster-0.12.0-SNAPSHOT1/conf/iotdb-engine.properties > > sed -i -e 's/6667/6669/g' > ./cluster/target/cluster-0.12.0-SNAPSHOT2/conf/iotdb-engine.properties > # 第二步: Unix/OS X/Windows (git bash or WSL) > > sed -i -e 's/31999/32000/g' > ./cluster/target/cluster-0.12.0-SNAPSHOT1/conf/iotdb-env.sh > > sed -i -e 's/31999/32001/g' > ./cluster/target/cluster-0.12.0-SNAPSHOT2/conf/iotdb-env.sh > > chmod -R 777 ./cluster/target/ > > nohup ./cluster/target/cluster-0.12.0-SNAPSHOT/sbin/start-node.sh > >/dev/null 2>&1 & > > nohup ./cluster/target/cluster-0.12.0-SNAPSHOT1/sbin/start-node.sh > -internal_meta_port 9005 -internal_data_port 40012 -cluster_rpc_port 55561 > >/dev/null 2>&1 & > > nohup ./cluster/target/cluster-0.12.0-SNAPSHOT2/sbin/start-node.sh > -internal_meta_port 9007 -internal_data_port 40014 -cluster_rpc_port 55562 > >/dev/null 2>&1 & > After that I can't connect iotdb with iotdb-cli,and there are error logs in > log_all.log. > Please refer to the attachment. > !image-2021-03-11-11-02-27-954.png!!image-2021-03-11-11-02-36-333.png! > # -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IOTDB-1179) spotless check confilcts with the checkstyle of sonar
[ https://issues.apache.org/jira/browse/IOTDB-1179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17294220#comment-17294220 ] Houliang Qi commented on IOTDB-1179: Thanks, [~sunjincheng121]， I have merged the newest codes and rerun my PR, the import conflicts errors are disappeared. > spotless check confilcts with the checkstyle of sonar > - > > Key: IOTDB-1179 > URL: https://issues.apache.org/jira/browse/IOTDB-1179 > Project: Apache IoTDB > Issue Type: Improvement > Components: Core/Others >Reporter: Houliang Qi >Assignee: sunjincheng >Priority: Major > Labels: pull-request-available > Attachments: image-2021-03-01-14-38-00-577.png, > image-2021-03-01-14-38-13-642.png, image-2021-03-01-14-38-24-089.png > > > When we submit one pr, the sonar check produces the following error, it's may > due to the spotless check's import order is _org.apache.iotdb,,javax,java,#_ > , while the check style is sortImportsInGroupAlphabetically, they're in > conflict > !image-2021-03-01-14-38-00-577.png! > !image-2021-03-01-14-38-13-642.png! > > !image-2021-03-01-14-38-24-089.png! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IOTDB-1179) spotless check confilcts with the checkstyle of sonar
Houliang Qi created IOTDB-1179: -- Summary: spotless check confilcts with the checkstyle of sonar Key: IOTDB-1179 URL: https://issues.apache.org/jira/browse/IOTDB-1179 Project: Apache IoTDB Issue Type: Improvement Components: Core/Others Reporter: Houliang Qi When we submit one pr, the sonar check produces the following error, it's because the spotless check's import order is _org.apache.iotdb,,javax,java,\#_ , while the check style is sortImportsInGroupAlphabetically, they're in conflict !image-2021-03-01-14-32-20-249.png! !image-2021-03-01-14-34-06-208.png! !image-2021-03-01-14-34-21-945.png! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IOTDB-1164) Optimize the executeBatch interface in JDBC
[ https://issues.apache.org/jira/browse/IOTDB-1164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Houliang Qi reassigned IOTDB-1164: -- Assignee: wangyanhong > Optimize the executeBatch interface in JDBC > --- > > Key: IOTDB-1164 > URL: https://issues.apache.org/jira/browse/IOTDB-1164 > Project: Apache IoTDB > Issue Type: Improvement > Components: JDBC >Reporter: Houliang Qi >Assignee: wangyanhong >Priority: Major > > At present, the executeBatch method in JDBC is executed separately for each > statement. > For the cluster version, each statement will be a raft log, which will lead > to the cost of the raft log scrambling for locks and the RPC cost between the > raft replication groups. > The insertRecords and insertTablets interfaces in session API also have the > same problem, for details please see the following links. > The solution is similar to the previous one. The only difference is that the > statements in the executeBatch interface may not only insert data, but also > have metadata operations(like set storage group, create timeseries and so > on). It is necessary to distinguish between metadata operations and data > operations. > > [1] https://issues.apache.org/jira/browse/IOTDB-1099 > [2] https://issues.apache.org/jira/browse/IOTDB-1163 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IOTDB-1172) Remove unexpected exception thrown when all CreateTimeseries opeartions are successful for CreateMultiTimeseries
[ https://issues.apache.org/jira/browse/IOTDB-1172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17288187#comment-17288187 ] Houliang Qi commented on IOTDB-1172: Hi, [~LebronAl] this bug has been fixed together in this pr [https://github.com/apache/iotdb/pull/2698] > Remove unexpected exception thrown when all CreateTimeseries opeartions are > successful for CreateMultiTimeseries > - > > Key: IOTDB-1172 > URL: https://issues.apache.org/jira/browse/IOTDB-1172 > Project: Apache IoTDB > Issue Type: Improvement >Reporter: Xinyu Tan >Priority: Major > Labels: pull-request-available > Fix For: master branch > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IOTDB-1171) Aggregate queries with value filtering are too slow in cluster version
Houliang Qi created IOTDB-1171: -- Summary: Aggregate queries with value filtering are too slow in cluster version Key: IOTDB-1171 URL: https://issues.apache.org/jira/browse/IOTDB-1171 Project: Apache IoTDB Issue Type: Improvement Components: Cluster Reporter: Houliang Qi Aggregation query with value filtering in 5-node, 3-replica cluster is too slow !https://code.bonc.com.cn/confluence/download/attachments/64001968/image2021-2-5%2015%3A17%3A48.png?version=1=1612509626000=v2! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IOTDB-1164) Optimize the executeBatch interface in JDBC
Houliang Qi created IOTDB-1164: -- Summary: Optimize the executeBatch interface in JDBC Key: IOTDB-1164 URL: https://issues.apache.org/jira/browse/IOTDB-1164 Project: Apache IoTDB Issue Type: Improvement Reporter: Houliang Qi -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IOTDB-1163) Optimize the insertion speed of insertRecords interface in Session
Houliang Qi created IOTDB-1163: -- Summary: Optimize the insertion speed of insertRecords interface in Session Key: IOTDB-1163 URL: https://issues.apache.org/jira/browse/IOTDB-1163 Project: Apache IoTDB Issue Type: Improvement Reporter: Houliang Qi Fix For: 0.12.0 At present, the insertRecords interface generates an InsertRowPlan for each record of data. In this way, a raft log will be generated in the cluster version. Because every raft log will be locked, it will bring a lot of overhead. At the same time, if some records belong to the same raft replication group, they can be sent to other nodes of this raft group as a raft log, which will reduce the transmission of RPC. For example, 10 records belong to the same raft replication group. If the 10 records are regarded as a raft log, one node needs one RPC. If each log is regarded as a raft log, it needs 10 RPCs. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IOTDB-1163) Optimize the insertion speed of insertRecords interface in Session
[ https://issues.apache.org/jira/browse/IOTDB-1163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Houliang Qi reassigned IOTDB-1163: -- Assignee: Houliang Qi > Optimize the insertion speed of insertRecords interface in Session > -- > > Key: IOTDB-1163 > URL: https://issues.apache.org/jira/browse/IOTDB-1163 > Project: Apache IoTDB > Issue Type: Improvement >Reporter: Houliang Qi >Assignee: Houliang Qi >Priority: Major > Fix For: 0.12.0 > > > At present, the insertRecords interface generates an InsertRowPlan for each > record of data. In this way, a raft log will be generated in the cluster > version. Because every raft log will be locked, it will bring a lot of > overhead. > At the same time, if some records belong to the same raft replication group, > they can be sent to other nodes of this raft group as a raft log, which will > reduce the transmission of RPC. > > For example, 10 records belong to the same raft replication group. If the 10 > records are regarded as a raft log, one node needs one RPC. If each log is > regarded as a raft log, it needs 10 RPCs. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IOTDB-1150) Support concurrent asynchronous execution of CreateMultiTimeSeriesPlan in distribuetd version
Houliang Qi created IOTDB-1150: -- Summary: Support concurrent asynchronous execution of CreateMultiTimeSeriesPlan in distribuetd version Key: IOTDB-1150 URL: https://issues.apache.org/jira/browse/IOTDB-1150 Project: Apache IoTDB Issue Type: Improvement Components: Cluster Reporter: Houliang Qi When using the _createMultiTimeseries()_ interface to create time series, a CreateMultiTimeSeriesPlan plan will be generated. In order to simplify the lock competition of the same data raft group, we split the CreateMultiTimeSeriesPlan plan into several sub CreateMultiTimeSeriesPlans according to different data raft groups, and each sub CreateMultiTimeSeriesPlans belongs to the same data raft group. However, we did not consider a problem, that is, these sub CreateMultiTimeSeriesPlans may belong to different storage groups. When applying these plans, we can not use the advantage of asynchronous concurrent applier, which makes it appropriate. As long as we encounter the CreateMultiTimeSeriesPlan plan, all operations are serial applied. Therefore, it needs to be optimized. The optimization method is also very simple. When splitting the plan, you can split it more finely. For timeseries that belongs to the same data group and the same SG, assemble one CreateMultiTimeSeriesPlan. In this way, when applying the plan, different SG of the same data group can be applied in parallel. The implementation of this part of code can refer to the split of InsertMultiTabletPlan. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IOTDB-1148) Client leak in sync client pool
Houliang Qi created IOTDB-1148: -- Summary: Client leak in sync client pool Key: IOTDB-1148 URL: https://issues.apache.org/jira/browse/IOTDB-1148 Project: Apache IoTDB Issue Type: Bug Components: Core/Cluster Reporter: Houliang Qi Fix For: 0.12.0 Attachments: image-2021-02-04-20-40-20-775.png When we use a 5-node, 3-replica cluster and repeat the following query 1000 times, we will have the following warning log. _SELECT count(s_82) FROM root.group_10.d_10 WHERE time >= 153737529 AND time <= 153737779 AND root.group_10.d_10.s_82 > -5_ This problem is caused by the following two reasons. When a filter query with timestamp and value is executed, if the query's timeseries does not exist locally, it will pull remote and put it into the local cache. The remote pull operation will get a client from the connection pool, but it will forget to put it back after use. Causes a client leak in the connection pool. At the same time, when judging whether timing exists locally, only mtree is judged, but not in the local cache, which aggravates the problem. To sum up, there are two problems as follows: 1. The connection in the client pool is leaked. Only the connection is created and not put back. 2. When judging whether the time sequence exists locally, the cache is not looked at. So as long as we solve the above two problems, we can solve this issue. !image-2021-02-04-20-40-20-775.png! This is because -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IOTDB-1148) Client leak in sync client pool
[ https://issues.apache.org/jira/browse/IOTDB-1148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Houliang Qi reassigned IOTDB-1148: -- Assignee: Houliang Qi > Client leak in sync client pool > --- > > Key: IOTDB-1148 > URL: https://issues.apache.org/jira/browse/IOTDB-1148 > Project: Apache IoTDB > Issue Type: Bug > Components: Core/Cluster >Reporter: Houliang Qi >Assignee: Houliang Qi >Priority: Major > Fix For: 0.12.0 > > Attachments: image-2021-02-04-20-40-20-775.png > > > When we use a 5-node, 3-replica cluster and repeat the following query 1000 > times, we will have the following warning log. > _SELECT count(s_82) FROM root.group_10.d_10 WHERE time >= 153737529 AND > time <= 153737779 AND root.group_10.d_10.s_82 > -5_ > This problem is caused by the following two reasons. When a filter query with > timestamp and value is executed, if the query's timeseries does not exist > locally, it will pull remote and put it into the local cache. The remote pull > operation will get a client from the connection pool, but it will forget to > put it back after use. Causes a client leak in the connection pool. > At the same time, when judging whether timing exists locally, only mtree is > judged, but not in the local cache, which aggravates the problem. > To sum up, there are two problems as follows: > 1. The connection in the client pool is leaked. Only the connection is > created and not put back. > 2. When judging whether the time sequence exists locally, the cache is not > looked at. > So as long as we solve the above two problems, we can solve this issue. > !image-2021-02-04-20-40-20-775.png! > > This is because -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IOTDB-1144) Only partial results are displayed with the show devices command
[ https://issues.apache.org/jira/browse/IOTDB-1144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17278653#comment-17278653 ] Houliang Qi commented on IOTDB-1144: Yes, [~wangchao316]， thanks remind, this is the same issue with the https://issues.apache.org/jira/browse/IOTDB-1134 I'will linked the issue and close IOTDB-1134 . > Only partial results are displayed with the show devices command > - > > Key: IOTDB-1144 > URL: https://issues.apache.org/jira/browse/IOTDB-1144 > Project: Apache IoTDB > Issue Type: Bug > Components: Cluster >Reporter: Houliang Qi >Assignee: Houliang Qi >Priority: Major > Labels: pull-request-available > Attachments: image-2021-02-02-18-49-57-858.png, > image-2021-02-02-18-50-06-784.png > > > In the cluster with 4 nodes and 3 replicas, when _show devices prefix_ > command is executed on one node, the result is empty, but it can be seen on > other nodes. > This is because the show device command is executed locally, not execute > globally. > *!image-2021-02-02-18-50-06-784.png!* -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IOTDB-1147) Concurrent bug error in FlushManager may cause NoSuchElementException error
Houliang Qi created IOTDB-1147: -- Summary: Concurrent bug error in FlushManager may 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 Fix For: 0.12.0 Attachments: image-2021-02-04-10-57-43-980.png, image-2021-02-04-10-57-53-288.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 t_sFileProcessorQueue.getFirst().getStorageGroupName()_ it may cause NoSuchElementException error. !image-2021-02-04-10-52-19-911.png! The error are as follows: !image-2021-02-04-10-56-04-613.png! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IOTDB-1147) Concurrent bug error in FlushManager may cause NoSuchElementException error
[ https://issues.apache.org/jira/browse/IOTDB-1147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Houliang Qi reassigned IOTDB-1147: -- Assignee: Houliang Qi > Concurrent bug error in FlushManager may 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 > Fix For: 0.12.0 > > Attachments: image-2021-02-04-10-57-43-980.png, > image-2021-02-04-10-57-53-288.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 > t_sFileProcessorQueue.getFirst().getStorageGroupName()_ it may cause > NoSuchElementException error. > !image-2021-02-04-10-52-19-911.png! > The error are as follows: > > !image-2021-02-04-10-56-04-613.png! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IOTDB-1144) Only partial results are displayed with the show devices command
[ https://issues.apache.org/jira/browse/IOTDB-1144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Houliang Qi reassigned IOTDB-1144: -- Assignee: Houliang Qi > Only partial results are displayed with the show devices command > - > > Key: IOTDB-1144 > URL: https://issues.apache.org/jira/browse/IOTDB-1144 > Project: Apache IoTDB > Issue Type: Bug > Components: Cluster >Reporter: Houliang Qi >Assignee: Houliang Qi >Priority: Major > Attachments: image-2021-02-02-18-49-57-858.png, > image-2021-02-02-18-50-06-784.png > > > In the cluster with 4 nodes and 3 replicas, when _show devices prefix_ > command is executed on one node, the result is empty, but it can be seen on > other nodes. > This is because the show device command is executed locally, not execute > globally. > *!image-2021-02-02-18-50-06-784.png!* -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IOTDB-1144) Only partial results are displayed with the show devices command
Houliang Qi created IOTDB-1144: -- Summary: Only partial results are displayed with the show devices command Key: IOTDB-1144 URL: https://issues.apache.org/jira/browse/IOTDB-1144 Project: Apache IoTDB Issue Type: Bug Components: Cluster Reporter: Houliang Qi Attachments: image-2021-02-02-18-49-57-858.png, image-2021-02-02-18-50-06-784.png In the cluster with 4 nodes and 3 replicas, when _show devices prefix_ command is executed on one node, the result is empty, but it can be seen on other nodes. This is because the show device command is executed locally, not execute globally. *!image-2021-02-02-18-50-06-784.png!* -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IOTDB-1139) cluster - SELECT LAST null
[ https://issues.apache.org/jira/browse/IOTDB-1139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17274324#comment-17274324 ] Houliang Qi commented on IOTDB-1139: !image-2021-01-29-18-56-08-148.png! I tried locally, however, it's ok sorry， I can not > cluster - SELECT LAST null > -- > > Key: IOTDB-1139 > URL: https://issues.apache.org/jira/browse/IOTDB-1139 > Project: Apache IoTDB > Issue Type: Bug >Reporter: Haimei Guo >Priority: Major > Attachments: image-2021-01-29-17-53-17-966.png, > image-2021-01-29-18-53-43-055.png, image-2021-01-29-18-56-08-148.png > > > cluster SELECT LAST throw exception in some timeseries > > ie. > insert into root.临时数据.可删.boolen(timestamp,66) values(111,444) > SELECT last 66 FROM root.临时数据.可删.boolen ; > !image-2021-01-29-17-53-17-966.png! > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IOTDB-1138) Compaction encountered some errors
Houliang Qi created IOTDB-1138: -- Summary: Compaction encountered some errors Key: IOTDB-1138 URL: https://issues.apache.org/jira/browse/IOTDB-1138 Project: Apache IoTDB Issue Type: Bug Components: Core/Engine Reporter: Houliang Qi Attachments: image-2021-01-29-17-23-53-280.png When using iotdb-benchmark to write continuously, some merge errors will be reported in the log as follows: !image-2021-01-29-17-23-53-280.png! besides, there are some bugs that are introduced by merge, for example: [https://github.com/apache/iotdb/issues/2549] [https://github.com/apache/iotdb/issues/2545] [https://github.com/apache/iotdb/pulls?q=is%3Apr+merge+is%3Aclosed] We are very happy to see the introduction of merge in version 0.11, but we are also a little worried about whether merge can really be applied in the production environment? Whether it is necessary to add a lot of tests specifically for merge？ -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IOTDB-1133) Reduce the code compilation time
[ https://issues.apache.org/jira/browse/IOTDB-1133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Houliang Qi reassigned IOTDB-1133: -- Assignee: Houliang Qi > Reduce the code compilation time > > > Key: IOTDB-1133 > URL: https://issues.apache.org/jira/browse/IOTDB-1133 > Project: Apache IoTDB > Issue Type: Improvement > Components: Others >Reporter: Houliang Qi >Assignee: Houliang Qi >Priority: Major > Labels: pull-request-available > Fix For: 0.12.0 > > Attachments: image-2021-01-27-19-31-44-993.png, > image-2021-01-27-19-31-51-791.png > > > Now, due to the introduction of vulnerabilities check, the code compilation > time is greatly increased, which makes developers need to wait a lot of time > for the compilation to complete when testing. I think it's better to add one > configuration when building the codes , so that when testing, we can disable > the vulnerabilities check. > And we can see from the result that, when disable the vulnerabilities check, > the compilation speed is more than doubled. > > !image-2021-01-27-19-31-44-993.png! > !image-2021-01-27-19-31-51-791.png! > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IOTDB-1133) Reduce the code compilation time
Houliang Qi created IOTDB-1133: -- Summary: Reduce the code compilation time Key: IOTDB-1133 URL: https://issues.apache.org/jira/browse/IOTDB-1133 Project: Apache IoTDB Issue Type: Improvement Components: Others Reporter: Houliang Qi Fix For: 0.12.0 Attachments: image-2021-01-27-19-31-44-993.png, image-2021-01-27-19-31-51-791.png Now, due to the introduction of vulnerabilities check, the code compilation time is greatly increased, which makes developers need to wait a lot of time for the compilation to complete when testing. I think it's better to add one configuration when building the codes , so that when testing, we can disable the vulnerabilities check. And we can see from the result that, when disable the vulnerabilities check, the compilation speed is more than doubled. !image-2021-01-27-19-28-23-110.png! !image-2021-01-27-19-28-40-603.png! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IOTDB-1122) Disable the pre-start customizations debug message
Houliang Qi created IOTDB-1122: -- Summary: Disable the pre-start customizations debug message Key: IOTDB-1122 URL: https://issues.apache.org/jira/browse/IOTDB-1122 Project: Apache IoTDB Issue Type: Improvement Components: Cluster Reporter: Houliang Qi Now, the distributed version of iotdb have its own data partition strategy, however, when start the iotdb, there have pre-start customizations codes, which is debug for tester, which should be comment out when releasing the the official version. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IOTDB-1020) [Distributed] Split the persist log buffer to better absorb ingestion
[ https://issues.apache.org/jira/browse/IOTDB-1020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Houliang Qi reassigned IOTDB-1020: -- Assignee: Houliang Qi > [Distributed] Split the persist log buffer to better absorb ingestion > - > > Key: IOTDB-1020 > URL: https://issues.apache.org/jira/browse/IOTDB-1020 > Project: Apache IoTDB > Issue Type: Improvement >Reporter: Houliang Qi >Assignee: Houliang Qi >Priority: Major > Labels: pull-request-available > > In the current implementation, we provide only one persist raft log buffer > for each SyncLogDequeSerializer, which means if the buffer is full, we will > have to wait until the buffer is flushed before we can write the next log, > thus creating spikes in ingestions. > So, it is beneficial to split the WAL buffer into a working one and a > flushing one, and if the last flush has completed before we ran out of the > current working one, we can directly swap them, and continue writes. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IOTDB-1111) load configuration -global command do not support in the distributed version
Houliang Qi created IOTDB-: -- Summary: load configuration -global command do not support in the distributed version Key: IOTDB- URL: https://issues.apache.org/jira/browse/IOTDB- Project: Apache IoTDB Issue Type: Bug Components: Cluster Reporter: Houliang Qi Attachments: image-2021-01-15-15-21-28-995.png When I review the code, I see there can support the following command, load configuration -global however, the server can not execute successfully, BTW, I am confused about why need the global keyword? !image-2021-01-15-15-21-28-995.png! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IOTDB-910) Support time range interval query of metadata(timeseries,devices) and so on
[ https://issues.apache.org/jira/browse/IOTDB-910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17263128#comment-17263128 ] Houliang Qi commented on IOTDB-910: --- one solution is to add the create/update time in the tags of the timeseries, when we create timeseries or update timeseries, we can change the create/update time in the tags. in other words, we can add two default tags with the timeseries, that is create time and update time. further on, how about adding one map in every MNode, then we can add create time and update time in the device node. > Support time range interval query of metadata(timeseries,devices) and so on > --- > > Key: IOTDB-910 > URL: https://issues.apache.org/jira/browse/IOTDB-910 > Project: Apache IoTDB > Issue Type: New Feature > Components: Core/Engine >Reporter: Houliang Qi >Priority: Major > > Maybe we can treate the metadata(timeseries) as special data like the > timeseries's values. and support metadata query like data query. > One way to do this is to add the metadata to one metadata_table, like the > information_schema.tables of mysql. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IOTDB-1099) Optimize insertablets logic in cluster module
[ https://issues.apache.org/jira/browse/IOTDB-1099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Houliang Qi reassigned IOTDB-1099: -- Assignee: Houliang Qi > Optimize insertablets logic in cluster module > - > > Key: IOTDB-1099 > URL: https://issues.apache.org/jira/browse/IOTDB-1099 > Project: Apache IoTDB > Issue Type: Improvement > Components: Core/Cluster >Reporter: Xinyu Tan >Assignee: Houliang Qi >Priority: Major > > Currently, cluster module will process insertablets rpc by spliting it to > multiple insertablet statements one by one, and each of them will take up a > raft log, which need to complete the RaftLogManager's lock and be replicated > to followers in one raft log. > In some user cases, a inserttablets will have 160 tablets, so this single > client insertablets rpc will take up 160 raft logs containing insertabletPlan > to replicate, which maybe optimized to one raft log containing > insertabletsPlan if these devices all belong to same data group; > Therefore, we can process one insertablets rpc by grouping them to several > raft logs containing insertabletsPlan according to these belonged data > groups, just like the createMultiTimeSeriesPlan in current implementation. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IOTDB-1096) [Distributed]Can not restart the servers when added one new node
Houliang Qi created IOTDB-1096: -- Summary: [Distributed]Can not restart the servers when added one new node Key: IOTDB-1096 URL: https://issues.apache.org/jira/browse/IOTDB-1096 Project: Apache IoTDB Issue Type: Bug Reporter: Houliang Qi Fix For: master branch when add one new node into the cluster, the server can not restart again due to the startServerCheck to check wether the node is in the seed nodes or not. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IOTDB-1005) [Distributed] Make the frame size of thrift scalable
[ https://issues.apache.org/jira/browse/IOTDB-1005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17244936#comment-17244936 ] Houliang Qi commented on IOTDB-1005: As we can see from the log, the auto-resize of the max frame size bring another problem, which will cause OOM, as we can see from the profile, the byte[] array consume about 18GB, which is generated by thrift thread. this analyze alose brings another one problem, its reasonable that the max thread client num is 1？ I think we should do the following two things: 1. There must be a segmentation mechanism to divide large requests into small requests, as far I know, apache HBase default max frame is 2MB, 2. The maximum number of threads needs to be reduced(now the default value is 1000), but some tests may be needed to set the appropriate size. [^log.out]!image-2020-12-07-10-52-44-343.png! > [Distributed] Make the frame size of thrift scalable > > > Key: IOTDB-1005 > URL: https://issues.apache.org/jira/browse/IOTDB-1005 > Project: Apache IoTDB > Issue Type: Improvement > Components: Core/Cluster >Reporter: Houliang Qi >Assignee: Houliang Qi >Priority: Major > Labels: pull-request-available > Attachments: image-2020-12-07-10-52-44-343.png, log.out > > > As described in IOTDB-998[1], when the snapshot size larger than the max > frame size, it would fail when do snapshot, another way is to make the frame > size of thrift is scalable. it would be easier than IOTDB-998 > [1]https://issues.apache.org/jira/browse/IOTDB-998 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IOTDB-1020) [Distributed] Split the persist log buffer to better absorb ingestion
Houliang Qi created IOTDB-1020: -- Summary: [Distributed] Split the persist log buffer to better absorb ingestion Key: IOTDB-1020 URL: https://issues.apache.org/jira/browse/IOTDB-1020 Project: Apache IoTDB Issue Type: Improvement Reporter: Houliang Qi In the current implementation, we provide only one persist raft log buffer for each SyncLogDequeSerializer, which means if the buffer is full, we will have to wait until the buffer is flushed before we can write the next log, thus creating spikes in ingestions. So, it is beneficial to split the WAL buffer into a working one and a flushing one, and if the last flush has completed before we ran out of the current working one, we can directly swap them, and continue writes. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IOTDB-1019) [Distributed] Memory control of the cluster engine
Houliang Qi created IOTDB-1019: -- Summary: [Distributed] Memory control of the cluster engine Key: IOTDB-1019 URL: https://issues.apache.org/jira/browse/IOTDB-1019 Project: Apache IoTDB Issue Type: Improvement Components: Core/Cluster, Core/Engine Reporter: Houliang Qi We are glad to see that robust memory control is provided in a stand-alone engine to prevent OOM. However, this memory control only considers the memory occupied by the single engine, and does not consider the memory occupied by the distributed engine (such as the raft logs kept in the memory), which may cause OOM in a distributed cluster. There are two possible solutions to this problem: 1. Set a configuration parameter to control the maximum memory in the view of a single engine (not the maximum memory of the JVM) 2. Consider the memory occupied by the cluster engine. I think the first one would easier and helpful enough. Any ideas? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IOTDB-1005) [Distributed] Make the frame size of thrift scalable
Houliang Qi created IOTDB-1005: -- Summary: [Distributed] Make the frame size of thrift scalable Key: IOTDB-1005 URL: https://issues.apache.org/jira/browse/IOTDB-1005 Project: Apache IoTDB Issue Type: Improvement Components: Core/Cluster Reporter: Houliang Qi Assignee: Houliang Qi As described in IOTDB-998[1], when the snapshot size larger than the max frame size, it would fail when do snapshot, another way is to make the frame size of thrift is scalable. it would be easier than IOTDB-998 [1]https://issues.apache.org/jira/browse/IOTDB-998 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IOTDB-991) JDBC count function result feedback a wrong data type
[ https://issues.apache.org/jira/browse/IOTDB-991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Houliang Qi reassigned IOTDB-991: - Assignee: XiangweiWei (was: wangyanhong) Resolution: Fixed > JDBC count function result feedback a wrong data type > -- > > Key: IOTDB-991 > URL: https://issues.apache.org/jira/browse/IOTDB-991 > Project: Apache IoTDB > Issue Type: Bug > Components: JDBC >Reporter: lming >Assignee: XiangweiWei >Priority: Major > Labels: easy-fix > > user connect IoTDB server by JDBC,execute sql statement like "count > timeservice group by level = ?" > The server should give the count result with the data type is > integer.Infact the data type of result is string,so that cause user couldn't > get the correct result in jdbc with count function. -- This message was sent by Atlassian Jira (v8.3.4#803005)
