[jira] [Assigned] (IOTDB-1631) Timeout when exporting large data volume

2021-09-16 Thread Xuan Ronaldo (Jira)


 [ 
https://issues.apache.org/jira/browse/IOTDB-1631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Xuan Ronaldo reassigned IOTDB-1631:
---

Assignee: (was: Xuan Ronaldo)

> Timeout when exporting large data volume
> 
>
> Key: IOTDB-1631
> URL: https://issues.apache.org/jira/browse/IOTDB-1631
> Project: Apache IoTDB
>  Issue Type: Bug
>  Components: Tools/Others
>Reporter: xiaozhihong
>Priority: Major
>
> Operate as follow:
> [xzh@i-s9p350bm apache-iotdb-0.13.0-SNAPSHOT-all-bin]$ ls
> conf data docs ext lib LICENSE licenses logs nohup.out NOTICE README.md 
> README_ZH.md RELEASE_NOTES.md sbin tools
> [xzh@i-s9p350bm apache-iotdb-0.13.0-SNAPSHOT-all-bin]$ ./tools/export-csv.sh 
> -h 127.0.0.1 -p 6667 -u root -pw root -td /home/xzh/import-export/data/
> --
> Starting IoTDB Client Export Script
> --
> ExportCsv> please input query: select * from root
> select * from root
> 16:04:27.897 [main] DEBUG org.apache.iotdb.session.Session - 
> EndPoint(ip:127.0.0.1, port:6667) execute sql select * from root
> Cannot dump result because: 701: Current query is time out, please check your 
> statement or modify timeout parameter.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (IOTDB-1694) Load with time partition enable

2021-09-16 Thread yusicheng (Jira)
yusicheng created IOTDB-1694:


 Summary: Load with time partition enable
 Key: IOTDB-1694
 URL: https://issues.apache.org/jira/browse/IOTDB-1694
 Project: Apache IoTDB
  Issue Type: Bug
  Components: Core/Server
Affects Versions: master branch
Reporter: yusicheng


loading file with time partition enable will cause "cannot find a suitable 
position"

step1:
  enable time partition
step2:
  load a dir which has some tsfiles with different timeseries
step3:
  because of the unorder list in loading dir, maybe an "cannot find a suitable 
position" message will be found, and the loading process will stop.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IOTDB-1693) IoTDB restart does not truncate broken ChunkGroup bug

2021-09-16 Thread Liuxuxin (Jira)


[ 
https://issues.apache.org/jira/browse/IOTDB-1693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17416002#comment-17416002
 ] 

Liuxuxin commented on IOTDB-1693:
-

https://github.com/apache/iotdb/pull/3947

> IoTDB restart does not truncate broken ChunkGroup bug
> -
>
> Key: IOTDB-1693
> URL: https://issues.apache.org/jira/browse/IOTDB-1693
> Project: Apache IoTDB
>  Issue Type: Bug
>Reporter: Liuxuxin
>Priority: Major
> Fix For: 0.12.2-SNAPSHOT
>
> Attachments: image-2021-09-16-07-59-48-616.png
>
>
> h1. Bug Description
> When restoring a level 0 tsfile whose writing was interrupted, the wrong use 
> of RestorableTsFileIOWriter will cause the file to have redundant ChunkGroup 
> after Wal is written. These ChunkGroups will not be indexed by Metadata, so 
> they will not cause query errors, but will cause redundant data in TsFile.
>  
> h1. Reproduce
> !image-2021-09-16-07-59-48-616.png!
> Add a System.exit(1) in MemTableFlushTask.ioTask, then run the IoTDB and 
> insert some data. When flushing the memtable, the system will exit, and the 
> writing tsfile is broken. Remove the System.exit(1) and restart the IoTDB, 
> the tsfile will be restore during the recover process. Use TsFileSequenceRead 
> to check the recovered tsfile, we will find out a broken ChunkGroup.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (IOTDB-1693) IoTDB restart does not truncate broken ChunkGroup bug

2021-09-16 Thread Liuxuxin (Jira)
Liuxuxin created IOTDB-1693:
---

 Summary: IoTDB restart does not truncate broken ChunkGroup bug
 Key: IOTDB-1693
 URL: https://issues.apache.org/jira/browse/IOTDB-1693
 Project: Apache IoTDB
  Issue Type: Bug
Reporter: Liuxuxin
 Fix For: 0.12.2-SNAPSHOT


When restoring a level 0 tsfile whose writing was interrupted, the wrong use of 
RestorableTsFileIOWriter will cause the file to have redundant ChunkGroup after 
Wal is written. These ChunkGroups will not be indexed by Metadata, so they will 
not cause query errors, but will cause redundant data in TsFile.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (IOTDB-1692) LIKE query:The matching string contains “\n”. No result can be found

2021-09-16 Thread Jira
刘珍 created IOTDB-1692:
-

 Summary: LIKE query:The matching string contains “\n”. No result 
can be found
 Key: IOTDB-1692
 URL: https://issues.apache.org/jira/browse/IOTDB-1692
 Project: Apache IoTDB
  Issue Type: Bug
  Components: Core/Server
Affects Versions: 0.12.2
Reporter: 刘珍


release 0.12.2 RC3

 set storage group to root.liketest;
 CREATE TIMESERIES root.liketest.dev1.s_1 WITH DATATYPE=TEXT, ENCODING=PLAIN;
 insert into root.liketest.dev1(time,s_1) values(1,'fix\nxyz')
 select * from root.liketest.dev1 where s_1 like 'fix\nxyz'
{color:#DE350B}*Empty set.*{color}

 select * from root.liketest.dev1 where s_1 = 'fix\nxyz'




--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (IOTDB-1691) Wrong way of calculating the vector's memory footprint

2021-09-16 Thread Yuan Tian (Jira)
Yuan Tian created IOTDB-1691:


 Summary: Wrong way of calculating the vector's memory footprint
 Key: IOTDB-1691
 URL: https://issues.apache.org/jira/browse/IOTDB-1691
 Project: Apache IoTDB
  Issue Type: Bug
  Components: Core/Engine
Reporter: Yuan Tian


Previously, we only had one MeasurementMNode for one vector in InsertTablePlan. 
However, after one updating, each sub sensor of vector has its own 
MeasurementMNode, causing more calculation of vector memory footprint here.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)