[jira] [Created] (IOTDB-113) Use intern string to reduce memory usage
Jialin Qiao created IOTDB-113: - Summary: Use intern string to reduce memory usage Key: IOTDB-113 URL: https://issues.apache.org/jira/browse/IOTDB-113 Project: Apache IoTDB Issue Type: Improvement Reporter: Jialin Qiao Each time series is represented by a device id and a measurement name, which are two strings. The memory usage may be large when there are too many time series. One possible improvement is using String.intern(), which is designed for reducing memory usage and improve performance. A blog about String.intern() is here (in Chinese) https://blog.csdn.net/SEU_Calvin/article/details/52291082 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IOTDB-97) Try compression in RPC
Jialin Qiao created IOTDB-97: Summary: Try compression in RPC Key: IOTDB-97 URL: https://issues.apache.org/jira/browse/IOTDB-97 Project: Apache IoTDB Issue Type: Improvement Reporter: Jialin Qiao When executing a batch insertion in JDBC with many insert statements (e.g., >1000), the message to be transferred will be very large. The write throughput may be improved by compressing the message transferred between client and server. Currently, thrift is used in RPC. The protocol we use is TBinaryProtocol which does not compact the data that transferred. There are two ways to improve: (1) Use TCompactProtocol instead of TBinaryProtocol. There are two classes need to be modified: JDBCService and IoTDBConnection. This protocol will compress the data in each RPC, I'm not sure whether this protocol is better when the size of transferred data is small. (2) We can just compress the data in executeBatch when the batch_size reaches a threshold. Add a compressed string that stores the SQLs in IoTDBStatement and use a flag to determine whether this field is used. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IOTDB-179) Add create matadata interfaces to Session
Jialin Qiao created IOTDB-179: - Summary: Add create matadata interfaces to Session Key: IOTDB-179 URL: https://issues.apache.org/jira/browse/IOTDB-179 Project: Apache IoTDB Issue Type: New Feature Reporter: Jialin Qiao Only insertBatch() is supported in Session, we need more efficient interfaces. The first are "set storage group to XXX" and "create timeseries..." -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Created] (IOTDB-181) Remove "first_value" and "last_value" in TsDigest
Jialin Qiao created IOTDB-181: - Summary: Remove "first_value" and "last_value" in TsDigest Key: IOTDB-181 URL: https://issues.apache.org/jira/browse/IOTDB-181 Project: Apache IoTDB Issue Type: Improvement Reporter: Jialin Qiao In TsDigest, we have five statistics: min_value, max_value, sum_value, first_value, last_value. When filtering page or chunk, we use min_value and max_value for a filter like "s1>10" or "s1<20". The sum value can be used in aggregation query "select sum(s1) from root...". However, it is difficult for me to come up with a scenario that uses "first_value" and "last_value" to filter data, and they are never used at all... So why not remove them? -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Created] (IOTDB-180) Get rid of JSON format in "show timeseries"
Jialin Qiao created IOTDB-180: - Summary: Get rid of JSON format in "show timeseries" Key: IOTDB-180 URL: https://issues.apache.org/jira/browse/IOTDB-180 Project: Apache IoTDB Issue Type: Wish Reporter: Jialin Qiao Attachments: image-2019-08-27-09-56-20-654.png, image-2019-08-27-09-56-28-577.png Currently, "show timeseries" prints result in JSON format, which is not friendly compared to "show timeseries root" in table format. !image-2019-08-27-09-56-20-654.png|width=463,height=538! !image-2019-08-27-09-56-28-577.png|width=694,height=458! Intuitively, I would expect that "show timeseries" works as "show timeseries root". Therefore, when users input a "show timeseries", I suggest that we treat it as "show timeseries root" and print results in table format. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Created] (IOTDB-193) Create metadata automatically in the insertion
Jialin Qiao created IOTDB-193: - Summary: Create metadata automatically in the insertion Key: IOTDB-193 URL: https://issues.apache.org/jira/browse/IOTDB-193 Project: Apache IoTDB Issue Type: New Feature Reporter: Jialin Qiao Setting storage group and creating time series can be troublesome when using IoTDB in applications. Let's look at the typical scenes: The devices send messages to Kafka. Each message includes: factoryId, deviceId, timestamp, s1_value, s2_value, s3_value. The consumer of Kafka needs to consume the messages and organize the data into an insert statement: "insert into root.factoryId.deviceId(time, s1, s2, s3) values(timestamp, s1_value, s2_value, s3_value)" Before inserting the data into IoTDB, the consumer needs to judge whether the storage group and time series are created before, which is not convenient. Typically, there are 3 ways to do that: # Caching the storage group and timeseries created before in the consumer # Query from IoTDB whether a storage group and timeseries exists # Directly create metadata regardless of whether created before Could IoTDB support creating metadata (at least time series) automatically when receiving an insertion? -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Created] (IOTDB-197) JXM connection failure
Jialin Qiao created IOTDB-197: - Summary: JXM connection failure Key: IOTDB-197 URL: https://issues.apache.org/jira/browse/IOTDB-197 Project: Apache IoTDB Issue Type: Bug Reporter: Jialin Qiao Attachments: image-2019-09-04-10-40-22-547.png When I try to use jvisualvm to connect IoTDB, the connection cannot be established. A potential solution is to set the -Djava.rmi.server.hostname=ip. We can dynamically get the ip address and set it to IOTDB_JMX_OPTS in iotdb-env.sh. !image-2019-09-04-10-40-22-547.png! -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Created] (IOTDB-188) Delete Storage Group
Jialin Qiao created IOTDB-188: - Summary: Delete Storage Group Key: IOTDB-188 URL: https://issues.apache.org/jira/browse/IOTDB-188 Project: Apache IoTDB Issue Type: New Feature Reporter: Jialin Qiao add “delete storage group xxx” interface, which delete all data and metadata of one storage group -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Created] (IOTDB-173) Add rpc interface to insert data
Jialin Qiao created IOTDB-173: - Summary: Add rpc interface to insert data Key: IOTDB-173 URL: https://issues.apache.org/jira/browse/IOTDB-173 Project: Apache IoTDB Issue Type: Improvement Reporter: Jialin Qiao Attachments: image-2019-08-23-12-20-32-821.png I used Jprofiler to profile the executBatch jdbc interface when inserting data, and found 70% of the time cost is parsing SQL by Antlr3. !image-2019-08-23-12-20-32-821.png! To accelerate the insertion speed, a new interface that bypasses SQL is needed. One way is to add an RPC interface for batch insert, and I am working on that. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Closed] (IOTDB-173) Add rpc interface to insert data
[ https://issues.apache.org/jira/browse/IOTDB-173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jialin Qiao closed IOTDB-173. - > Add rpc interface to insert data > > > Key: IOTDB-173 > URL: https://issues.apache.org/jira/browse/IOTDB-173 > Project: Apache IoTDB > Issue Type: Improvement >Reporter: Jialin Qiao >Priority: Major > Labels: pull-request-available > Fix For: 0.9.0 > > Attachments: image-2019-08-23-12-20-32-821.png > > Time Spent: 10m > Remaining Estimate: 0h > > I used Jprofiler to profile the executBatch jdbc interface when inserting > data, and found 70% of the time cost is parsing SQL by Antlr3. > !image-2019-08-23-12-20-32-821.png! > To accelerate the insertion speed, a new interface that bypasses SQL is > needed. > One way is to add an RPC interface for batch insert, and I am working on that. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Created] (IOTDB-191) Enrich Session interfaces
Jialin Qiao created IOTDB-191: - Summary: Enrich Session interfaces Key: IOTDB-191 URL: https://issues.apache.org/jira/browse/IOTDB-191 Project: Apache IoTDB Issue Type: New Feature Reporter: Jialin Qiao The module "Session" is an RPC interface for users, which is more efficient than JDBC. Currently, it only has 3 interfaces: (1) ser storage group (2) create time series (3) insert batch. Other interfaces such as delete time series, the query could be added. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Closed] (IOTDB-179) Add create matadata interfaces to Session
[ https://issues.apache.org/jira/browse/IOTDB-179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jialin Qiao closed IOTDB-179. - Fix Version/s: 0.9.0 Resolution: Fixed > Add create matadata interfaces to Session > - > > Key: IOTDB-179 > URL: https://issues.apache.org/jira/browse/IOTDB-179 > Project: Apache IoTDB > Issue Type: New Feature >Reporter: Jialin Qiao >Priority: Major > Labels: pull-request-available > Fix For: 0.9.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Only insertBatch() is supported in Session, we need more efficient > interfaces. > The first are "set storage group to XXX" and "create timeseries..." -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Created] (IOTDB-216) Release of 0.8.1
Jialin Qiao created IOTDB-216: - Summary: Release of 0.8.1 Key: IOTDB-216 URL: https://issues.apache.org/jira/browse/IOTDB-216 Project: Apache IoTDB Issue Type: Task Reporter: Jialin Qiao This is a bug-fix version of 0.8.0 -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Created] (IOTDB-217) A new predicate of time
Jialin Qiao created IOTDB-217: - Summary: A new predicate of time Key: IOTDB-217 URL: https://issues.apache.org/jira/browse/IOTDB-217 Project: Apache IoTDB Issue Type: New Feature Reporter: Jialin Qiao I have encountered an issue that our SQL cannot support well. The scenario is: I want to get the data between 9:00am to 12:00am in each day last week. Could we add a new sql to do that? The sql maybe like this: select s0 from root.d0 where time >= now()-1week and time <= now() groupby time(1d) innerInterval(9h, 12h) -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Created] (IOTDB-218) Using exception instead of returning true/false
Jialin Qiao created IOTDB-218: - Summary: Using exception instead of returning true/false Key: IOTDB-218 URL: https://issues.apache.org/jira/browse/IOTDB-218 Project: Apache IoTDB Issue Type: Improvement Reporter: Jialin Qiao "boolean insert(InsertPlan insertPlan) throws ProcessorException;" For example, this is the insert interface in IQueryProcessExecutor, we should use exception instead of returning true or false because exception could return a message to the client. Otherwise, the client only know an "Execute statement error", which is not friendly at all. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Closed] (IOTDB-97) Try compression in RPC
[ https://issues.apache.org/jira/browse/IOTDB-97?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jialin Qiao closed IOTDB-97. Fix Version/s: 0.9.0 Resolution: Fixed > Try compression in RPC > -- > > Key: IOTDB-97 > URL: https://issues.apache.org/jira/browse/IOTDB-97 > Project: Apache IoTDB > Issue Type: Improvement >Reporter: Jialin Qiao >Priority: Minor > Fix For: 0.9.0 > > > When executing a batch insertion in JDBC with many insert statements (e.g., > >1000), the message to be transferred will be very large. The write > throughput may be improved by compressing the message transferred between > client and server. > Currently, thrift is used in RPC. The protocol we use is TBinaryProtocol > which does not compact the data that transferred. There are two ways to > improve: > (1) Use TCompactProtocol instead of TBinaryProtocol. There are two classes > need to be modified: JDBCService and IoTDBConnection. This protocol will > compress the data in each RPC, I'm not sure whether this protocol is better > when the size of transferred data is small. > (2) We can just compress the data in executeBatch when the batch_size reaches > a threshold. Add a compressed string that stores the SQLs in IoTDBStatement > and use a flag to determine whether this field is used. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Created] (IOTDB-205) Support retention policy
Jialin Qiao created IOTDB-205: - Summary: Support retention policy Key: IOTDB-205 URL: https://issues.apache.org/jira/browse/IOTDB-205 Project: Apache IoTDB Issue Type: New Feature Reporter: Jialin Qiao Many applications use TSDBs to just store recent data for a period of time. For example, 10 days, and older data will be deleted automatically. Influxdb also supports this function called retention policy. It would be great that we also support this. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Created] (IOTDB-203) A new result set format
Jialin Qiao created IOTDB-203: - Summary: A new result set format Key: IOTDB-203 URL: https://issues.apache.org/jira/browse/IOTDB-203 Project: Apache IoTDB Issue Type: New Feature Reporter: Jialin Qiao When executing a SQL like "select d1.s1, d2.s1 from root.sg1", the default result set format in IoTDB is "time, root.sg1.d1.s1, root.sg1.d2.s1" 1 , 1, 1 2, 2, 2 However, some users want to get another format, The results could be grouped by device, then sorted by time. "time, deviceId, s1". 1, root.sg1.d1, 1 2, root.sg1.d2, 2 This can be done in the client, but it would be better if we support this format in the server. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Created] (IOTDB-220) hot-load configuration file
Jialin Qiao created IOTDB-220: - Summary: hot-load configuration file Key: IOTDB-220 URL: https://issues.apache.org/jira/browse/IOTDB-220 Project: Apache IoTDB Issue Type: New Feature Reporter: Jialin Qiao it's a practical function to hot-load the configuration file without restarting IoTDB. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IOTDB-228) Catch RuntimeException in interting to memtable
Jialin Qiao created IOTDB-228: - Summary: Catch RuntimeException in interting to memtable Key: IOTDB-228 URL: https://issues.apache.org/jira/browse/IOTDB-228 Project: Apache IoTDB Issue Type: Improvement Reporter: Jialin Qiao When parsing data values into different types in the inserting process, RuntimeException often occurs and will terminate the connection. It's better to catch this and return message to users. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IOTDB-233) Keep MetadataPlan clear
Jialin Qiao created IOTDB-233: - Summary: Keep MetadataPlan clear Key: IOTDB-233 URL: https://issues.apache.org/jira/browse/IOTDB-233 Project: Apache IoTDB Issue Type: Improvement Reporter: Jialin Qiao The metadata operator and metadataPlan have both a path and a deletePathList, which is confusing. It seems that they are used in different scenarios: private Path path; (for set storage group, create timeseries) private List deletePathList; (for delete timeseries) It's better to make it clear. Maybe by using more types of physical plans. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (IOTDB-228) Catch RuntimeException in interting to memtable
[ https://issues.apache.org/jira/browse/IOTDB-228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jialin Qiao closed IOTDB-228. - Fix Version/s: 0.9.0 Resolution: Fixed > Catch RuntimeException in interting to memtable > --- > > Key: IOTDB-228 > URL: https://issues.apache.org/jira/browse/IOTDB-228 > Project: Apache IoTDB > Issue Type: Improvement >Reporter: Jialin Qiao >Priority: Major > Fix For: 0.9.0 > > > When parsing data values into different types in the inserting process, > RuntimeException often occurs and will terminate the connection. It's better > to catch this and return message to users. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IOTDB-225) Support Druid connection pool
Jialin Qiao created IOTDB-225: - Summary: Support Druid connection pool Key: IOTDB-225 URL: https://issues.apache.org/jira/browse/IOTDB-225 Project: Apache IoTDB Issue Type: New Feature Reporter: Jialin Qiao -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (IOTDB-278) remove tsfile-format.properties
[ https://issues.apache.org/jira/browse/IOTDB-278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jialin Qiao closed IOTDB-278. - Fix Version/s: 0.9.0 Resolution: Fixed > remove tsfile-format.properties > --- > > Key: IOTDB-278 > URL: https://issues.apache.org/jira/browse/IOTDB-278 > Project: Apache IoTDB > Issue Type: Improvement >Reporter: Jialin Qiao >Priority: Major > Labels: pull-request-available > Fix For: 0.9.0 > > Time Spent: 10m > Remaining Estimate: 0h > > # merge tsfile-format.properties to iotdb-engine.properties > # add configuration class for tsfile, let users set configurations through > API > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (IOTDB-273) Parallel Recovery
[ https://issues.apache.org/jira/browse/IOTDB-273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jialin Qiao closed IOTDB-273. - Fix Version/s: 0.9.0 Resolution: Fixed > Parallel Recovery > - > > Key: IOTDB-273 > URL: https://issues.apache.org/jira/browse/IOTDB-273 > Project: Apache IoTDB > Issue Type: Improvement >Reporter: Jialin Qiao >Priority: Major > Labels: pull-request-available > Fix For: 0.9.0 > > Time Spent: 10m > Remaining Estimate: 0h > > When restarting IoTDB, we recover each storage group one by one, which costs > 20min for 8GB WAL. > The restart can speed up by parallelly recovery storage groups. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IOTDB-284) Do not write empty page
Jialin Qiao created IOTDB-284:
-
Summary: Do not write empty page
Key: IOTDB-284
URL: https://issues.apache.org/jira/browse/IOTDB-284
Project: Apache IoTDB
Issue Type: Improvement
Reporter: Jialin Qiao
SET STORAGE GROUP TO root.turbine;
CREATE TIMESERIES root.turbine.d2.s0 WITH DATATYPE=INT32, ENCODING=RLE;
insert into root.turbine.d2(timestamp,s0) values(2,25.3);
flush
When receiving the insert statement, IoTDB will create a ChunkWriterImpl, but
the value will not be inserted because of type error.
The empty ChunkWriterImpl will be written when meeting the 'flush' command.
Then, the server will log an error:
19:33:24.667 [pool-6-IoTDB-Flush-SubTask-ServerServiceImpl-thread-2] ERROR
org.apache.iotdb.tsfile.write.chunk.ChunkBuffer - Write page error,
[s0,INT32,RLE,{},UNCOMPRESSED], minTime:-9223372036854775808, maxTime:0
We can check the data type before creating the ChunkWriterImpl to avoid write
empty ChunkWriterImpl.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (IOTDB-181) Remove "first_value" and "last_value" in TsDigest
[ https://issues.apache.org/jira/browse/IOTDB-181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jialin Qiao closed IOTDB-181. - Resolution: Later > Remove "first_value" and "last_value" in TsDigest > - > > Key: IOTDB-181 > URL: https://issues.apache.org/jira/browse/IOTDB-181 > Project: Apache IoTDB > Issue Type: Improvement >Reporter: Jialin Qiao >Priority: Minor > > In TsDigest, we have five statistics: min_value, max_value, sum_value, > first_value, last_value. > When filtering page or chunk, we use min_value and max_value for a filter > like "s1>10" or "s1<20". > The sum value can be used in aggregation query "select sum(s1) from root...". > However, it is difficult for me to come up with a scenario that uses > "first_value" and "last_value" to filter data, and they are never used at > all... > So why not remove them? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (IOTDB-113) Use intern string to reduce memory usage
[ https://issues.apache.org/jira/browse/IOTDB-113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jialin Qiao closed IOTDB-113. - Fix Version/s: 0.9.0 Resolution: Fixed > Use intern string to reduce memory usage > > > Key: IOTDB-113 > URL: https://issues.apache.org/jira/browse/IOTDB-113 > Project: Apache IoTDB > Issue Type: Improvement >Reporter: Jialin Qiao >Priority: Minor > Fix For: 0.9.0 > > > Each time series is represented by a device id and a measurement name, which > are two strings. The memory usage may be large when there are too many time > series. > One possible improvement is using String.intern(), which is designed for > reducing memory usage and improve performance. > A blog about String.intern() is here (in Chinese) > https://blog.csdn.net/SEU_Calvin/article/details/52291082 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IOTDB-303) Lost users information when upgrading 0.8.x to 0.9.0
Jialin Qiao created IOTDB-303: - Summary: Lost users information when upgrading 0.8.x to 0.9.0 Key: IOTDB-303 URL: https://issues.apache.org/jira/browse/IOTDB-303 Project: Apache IoTDB Issue Type: Bug Reporter: Jialin Qiao If creating other users in IoTDB, the upgrade from 0.8.x to 0.9.0 will lost users except "root". In other words, the data/system/user/*.profile is not compatible between 0.8.x and 0.9.0. Currently, we remove all *.profile and create a new root user with password root. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IOTDB-298) Refactor the "last" and "first" aggregators
Jialin Qiao created IOTDB-298: - Summary: Refactor the "last" and "first" aggregators Key: IOTDB-298 URL: https://issues.apache.org/jira/browse/IOTDB-298 Project: Apache IoTDB Issue Type: Improvement Reporter: Jialin Qiao We have two aggregators: last -> return the value of the last data point max_time -> return the time of the last data point However, we do not have an aggregator that returns the last time-value pair. This is very antihuman in a time-series database :(:(:( I suggest changing the "last" aggregator to return the last time-value pair and removing the max_time aggregator. Similar to the "first" aggregator. One thing we need to pay attention: for example, select last(s1), last(s2) from root.sg1.d1 . If the two series have different last time, how we organize the ResultSet? Maybe each line represents a last point. List this: time last(s1), last(s2) 1, 1, null 2, null, 1 Or we could forbid using the last aggregator on two series at the same time. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IOTDB-299) Merge ChunkBuffer to ChunkWriterImpl
Jialin Qiao created IOTDB-299: - Summary: Merge ChunkBuffer to ChunkWriterImpl Key: IOTDB-299 URL: https://issues.apache.org/jira/browse/IOTDB-299 Project: Apache IoTDB Issue Type: Improvement Reporter: Jialin Qiao ChunkBuffer has many fields and functions, which makes it not like a buffer but like a writer. Merge it into ChunkWriterImpl will make the write process clearer. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IOTDB-342) Merge BytesUtils with ReadWriteIOUtils
Jialin Qiao created IOTDB-342: - Summary: Merge BytesUtils with ReadWriteIOUtils Key: IOTDB-342 URL: https://issues.apache.org/jira/browse/IOTDB-342 Project: Apache IoTDB Issue Type: Improvement Reporter: Jialin Qiao In the TsFile module, there are BytesUtils and ReadWriteIOUtils for serializing and deserializing objects. It's better to merge them and leave one. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IOTDB-334) Move limit parser to Server side
Jialin Qiao created IOTDB-334:
-
Summary: Move limit parser to Server side
Key: IOTDB-334
URL: https://issues.apache.org/jira/browse/IOTDB-334
Project: Apache IoTDB
Issue Type: Improvement
Reporter: Jialin Qiao
In our query process, SQL will be analyzed by Antlr in the server-side, then
generated to a logical plan.
However, query SQL is also parsed in the client (IoTDBQueryResultSet) by the
following statement to get the value of slimit and limit.
String[] splited = sql.toUpperCase().split("\\s+");
This causes extra parsing for a query, which will slow down the query speed.
I recommend moving the limit parsing to the server-side.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (IOTDB-338) Meet error when disconnecting with the server
[
https://issues.apache.org/jira/browse/IOTDB-338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jialin Qiao closed IOTDB-338.
-
Resolution: Fixed
[https://github.com/apache/incubator-iotdb/pull/637]
> Meet error when disconnecting with the server
> -
>
> Key: IOTDB-338
> URL: https://issues.apache.org/jira/browse/IOTDB-338
> Project: Apache IoTDB
> Issue Type: Bug
>Reporter: Jialin Qiao
>Priority: Major
>
> The client-thread in server meet error when the client disconnect with server:
>
> {code:java}
> //代码占位符
> 09:09:42.140 [pool-2-IoTDB-JDBC-Client-thread-1] ERROR
> org.apache.thrift.server.TThreadPoolServer - Thrift error occurred during
> processing of message.09:09:42.140 [pool-2-IoTDB-JDBC-Client-thread-1] ERROR
> org.apache.thrift.server.TThreadPoolServer - Thrift error occurred during
> processing of message.org.apache.thrift.transport.TTransportException: null
> at
> org.apache.thrift.transport.TIOStreamTransport.read(TIOStreamTransport.java:132)
> at org.apache.thrift.transport.TTransport.readAll(TTransport.java:86) at
> org.apache.thrift.protocol.TBinaryProtocol.readAll(TBinaryProtocol.java:425)
> at
> org.apache.thrift.protocol.TBinaryProtocol.readI32(TBinaryProtocol.java:321)
> at
> org.apache.thrift.protocol.TBinaryProtocol.readMessageBegin(TBinaryProtocol.java:225)
> at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:27) at
> org.apache.thrift.server.TThreadPoolServer$WorkerProcess.run(TThreadPoolServer.java:310)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (IOTDB-357) NullPointerException in ActiveTimeSeriesCounter
[
https://issues.apache.org/jira/browse/IOTDB-357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jialin Qiao closed IOTDB-357.
-
Resolution: Fixed
> NullPointerException in ActiveTimeSeriesCounter
> ---
>
> Key: IOTDB-357
> URL: https://issues.apache.org/jira/browse/IOTDB-357
> Project: Apache IoTDB
> Issue Type: Bug
>Reporter: Jialin Qiao
>Priority: Major
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Start a empty IoTDB, execute 3 sql:
> {code:java}
> SET STORAGE GROUP TO root.turbine;
> CREATE TIMESERIES root.turbine.d2.s0 WITH DATATYPE=DOUBLE, ENCODING=GORILLA;
> insert into root.turbine.d2(timestamp,s0) values(2,25.3);{code}
> Kill the server and restart, then you will see:
> {code:java}
> 11:37:45.157 [pool-1-IoTDB-Recovery-Thread-Pool-thread-1] ERROR
> org.apache.iotdb.db.conf.adapter.ActiveTimeSeriesCounter - Storage group
> root.turbine- registers active time series root.turbine.d2.s0
> failed11:37:45.157 [pool-1-IoTDB-Recovery-Thread-Pool-thread-1] ERROR
> org.apache.iotdb.db.conf.adapter.ActiveTimeSeriesCounter - Storage group
> root.turbine- registers active time series root.turbine.d2.s0
> failedjava.lang.NullPointerException: null at
> org.apache.iotdb.db.conf.adapter.ActiveTimeSeriesCounter.offer(ActiveTimeSeriesCounter.java:65)
> at
> org.apache.iotdb.db.engine.flush.MemTableFlushTask.syncFlushMemTable(MemTableFlushTask.java:87)
> at
> org.apache.iotdb.db.writelog.recover.TsFileRecoverPerformer.redoLogs(TsFileRecoverPerformer.java:213)
> at
> org.apache.iotdb.db.writelog.recover.TsFileRecoverPerformer.recover(TsFileRecoverPerformer.java:143)
> at
> org.apache.iotdb.db.engine.storagegroup.StorageGroupProcessor.recoverSeqFiles(StorageGroupProcessor.java:294)
> at
> org.apache.iotdb.db.engine.storagegroup.StorageGroupProcessor.recover(StorageGroupProcessor.java:223)
> at
> org.apache.iotdb.db.engine.storagegroup.StorageGroupProcessor.(StorageGroupProcessor.java:210)
> at
> org.apache.iotdb.db.engine.StorageEngine.lambda$new$0(StorageEngine.java:119)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)11:37:45.158
> [pool-1-IoTDB-Recovery-Thread-Pool-thread-1] ERROR
> org.apache.iotdb.db.conf.adapter.ActiveTimeSeriesCounter - Update
> root.turbine- active ratio failedjava.lang.NullPointerException: null at
> org.apache.iotdb.db.conf.adapter.ActiveTimeSeriesCounter.updateActiveRatio(ActiveTimeSeriesCounter.java:79)
> at
> org.apache.iotdb.db.engine.flush.MemTableFlushTask.syncFlushMemTable(MemTableFlushTask.java:91)
> at
> org.apache.iotdb.db.writelog.recover.TsFileRecoverPerformer.redoLogs(TsFileRecoverPerformer.java:213)
> at
> org.apache.iotdb.db.writelog.recover.TsFileRecoverPerformer.recover(TsFileRecoverPerformer.java:143)
> at
> org.apache.iotdb.db.engine.storagegroup.StorageGroupProcessor.recoverSeqFiles(StorageGroupProcessor.java:294)
> at
> org.apache.iotdb.db.engine.storagegroup.StorageGroupProcessor.recover(StorageGroupProcessor.java:223)
> at
> org.apache.iotdb.db.engine.storagegroup.StorageGroupProcessor.(StorageGroupProcessor.java:210)
> at
> org.apache.iotdb.db.engine.StorageEngine.lambda$new$0(StorageEngine.java:119)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {code}
>
>
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IOTDB-338) Meet error when disconnecting with the server
Jialin Qiao created IOTDB-338:
-
Summary: Meet error when disconnecting with the server
Key: IOTDB-338
URL: https://issues.apache.org/jira/browse/IOTDB-338
Project: Apache IoTDB
Issue Type: Bug
Affects Versions: 0.9.0
Reporter: Jialin Qiao
The client-thread in server meet error when the client disconnect with server:
{code:java}
//代码占位符
09:09:42.140 [pool-2-IoTDB-JDBC-Client-thread-1] ERROR
org.apache.thrift.server.TThreadPoolServer - Thrift error occurred during
processing of message.09:09:42.140 [pool-2-IoTDB-JDBC-Client-thread-1] ERROR
org.apache.thrift.server.TThreadPoolServer - Thrift error occurred during
processing of message.org.apache.thrift.transport.TTransportException: null at
org.apache.thrift.transport.TIOStreamTransport.read(TIOStreamTransport.java:132)
at org.apache.thrift.transport.TTransport.readAll(TTransport.java:86) at
org.apache.thrift.protocol.TBinaryProtocol.readAll(TBinaryProtocol.java:425) at
org.apache.thrift.protocol.TBinaryProtocol.readI32(TBinaryProtocol.java:321) at
org.apache.thrift.protocol.TBinaryProtocol.readMessageBegin(TBinaryProtocol.java:225)
at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:27) at
org.apache.thrift.server.TThreadPoolServer$WorkerProcess.run(TThreadPoolServer.java:310)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (IOTDB-218) Using exception instead of returning true/false
[ https://issues.apache.org/jira/browse/IOTDB-218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jialin Qiao closed IOTDB-218. - Resolution: Fixed > Using exception instead of returning true/false > --- > > Key: IOTDB-218 > URL: https://issues.apache.org/jira/browse/IOTDB-218 > Project: Apache IoTDB > Issue Type: Improvement >Reporter: Jialin Qiao >Priority: Major > Labels: 0.8.0, pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > "boolean insert(InsertPlan insertPlan) throws ProcessorException;" > For example, this is the insert interface in IQueryProcessExecutor, we should > use exception instead of returning true or false because exception could > return a message to the client. Otherwise, the client only know an "Execute > statement error", which is not friendly at all. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (IOTDB-220) hot-load configuration file
[ https://issues.apache.org/jira/browse/IOTDB-220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jialin Qiao closed IOTDB-220. - Resolution: Fixed > hot-load configuration file > --- > > Key: IOTDB-220 > URL: https://issues.apache.org/jira/browse/IOTDB-220 > Project: Apache IoTDB > Issue Type: New Feature >Reporter: Jialin Qiao >Priority: Minor > Labels: easy-fix, pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > it's a practical function to hot-load the configuration file without > restarting IoTDB. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IOTDB-274) Refactor MManager
Jialin Qiao created IOTDB-274: - Summary: Refactor MManager Key: IOTDB-274 URL: https://issues.apache.org/jira/browse/IOTDB-274 Project: Apache IoTDB Issue Type: Improvement Reporter: Jialin Qiao The code of MManager needs to be refactored. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IOTDB-275) Separate IoTDB JDK configuration with server
Jialin Qiao created IOTDB-275: - Summary: Separate IoTDB JDK configuration with server Key: IOTDB-275 URL: https://issues.apache.org/jira/browse/IOTDB-275 Project: Apache IoTDB Issue Type: New Feature Reporter: Jialin Qiao We want to let IoTDB to use an independent JDK instead of that in system environment. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IOTDB-261) Special characters in Session
Jialin Qiao created IOTDB-261:
-
Summary: Special characters in Session
Key: IOTDB-261
URL: https://issues.apache.org/jira/browse/IOTDB-261
Project: Apache IoTDB
Issue Type: Bug
Affects Versions: 0.9.0-SNAPSHOT
Reporter: Jialin Qiao
When using Session to set storage group or create time series, special
character in the path will cause an error in mlog.txt, which impacts the
restart and recover of IoTDB.
session.setStorageGroup("root.tur_\n\t_bine");
session.createTimeseries("root.turbine.d1.s_\n\t_1", TSDataType.INT64,
TSEncoding.RLE, CompressionType.SNAPPY);
It's better to reject these characters in the Session.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (IOTDB-205) Support retention policy
[ https://issues.apache.org/jira/browse/IOTDB-205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jialin Qiao closed IOTDB-205. - Fix Version/s: 0.9.0 Resolution: Fixed > Support retention policy > > > Key: IOTDB-205 > URL: https://issues.apache.org/jira/browse/IOTDB-205 > Project: Apache IoTDB > Issue Type: New Feature >Reporter: Jialin Qiao >Priority: Major > Labels: pull-request-available > Fix For: 0.9.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Many applications use TSDBs to just store recent data for a period of time. > For example, 10 days, and older data will be deleted automatically. Influxdb > also supports this function called retention policy. > It would be great that we also support this. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (IOTDB-233) Keep MetadataPlan clear
[ https://issues.apache.org/jira/browse/IOTDB-233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jialin Qiao closed IOTDB-233. - Fix Version/s: 0.9.0 Resolution: Fixed > Keep MetadataPlan clear > --- > > Key: IOTDB-233 > URL: https://issues.apache.org/jira/browse/IOTDB-233 > Project: Apache IoTDB > Issue Type: Improvement >Reporter: Jialin Qiao >Priority: Minor > Labels: pull-request-available > Fix For: 0.9.0 > > Time Spent: 20m > Remaining Estimate: 0h > > The metadata operator and metadataPlan have both a path and a deletePathList, > which is confusing. It seems that they are used in different scenarios: > private Path path; (for set storage group, create timeseries) > private List deletePathList; (for delete timeseries) > > It's better to make it clear. Maybe by using more types of physical plans. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IOTDB-278) remove tsfile-format.properties
Jialin Qiao created IOTDB-278: - Summary: remove tsfile-format.properties Key: IOTDB-278 URL: https://issues.apache.org/jira/browse/IOTDB-278 Project: Apache IoTDB Issue Type: Improvement Reporter: Jialin Qiao # merge tsfile-format.properties to iotdb-engine.properties # add configuration class for tsfile, let users set configurations through API -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IOTDB-279) Merge TsDigest into Statistics
Jialin Qiao created IOTDB-279: - Summary: Merge TsDigest into Statistics Key: IOTDB-279 URL: https://issues.apache.org/jira/browse/IOTDB-279 Project: Apache IoTDB Issue Type: Improvement Reporter: Jialin Qiao As I observe, TsDigest is only the ByteBuffer format of Statistics, so why not merge them, which could make the code clear. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IOTDB-280) Remove ChunkBufferPool
Jialin Qiao created IOTDB-280: - Summary: Remove ChunkBufferPool Key: IOTDB-280 URL: https://issues.apache.org/jira/browse/IOTDB-280 Project: Apache IoTDB Issue Type: Improvement Reporter: Jialin Qiao ChunkBufferPool has no effect on improving performance, it can be removed for a clean constructor of ChunkWriterImpl. ChunkWriterImpl could receive a MeasuremnetSchema and construct a ChunkBuffer inside. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IOTDB-281) Add powered by on the website
Jialin Qiao created IOTDB-281: - Summary: Add powered by on the website Key: IOTDB-281 URL: https://issues.apache.org/jira/browse/IOTDB-281 Project: Apache IoTDB Issue Type: Improvement Reporter: Jialin Qiao We could add the logo of companies powered by IoTDB on the website. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (IOTDB-188) Delete Storage Group in Session and SQL interface
[ https://issues.apache.org/jira/browse/IOTDB-188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jialin Qiao closed IOTDB-188. - Fix Version/s: 0.9.0 Resolution: Fixed > Delete Storage Group in Session and SQL interface > - > > Key: IOTDB-188 > URL: https://issues.apache.org/jira/browse/IOTDB-188 > Project: Apache IoTDB > Issue Type: New Feature >Reporter: Jialin Qiao >Priority: Major > Labels: pull-request-available > Fix For: 0.9.0 > > Time Spent: 10m > Remaining Estimate: 0h > > add “delete storage group xxx” interface, which delete all data and metadata > of one storage group -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (IOTDB-193) Create schema automatically in the insertion
[ https://issues.apache.org/jira/browse/IOTDB-193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jialin Qiao closed IOTDB-193. - Fix Version/s: 0.9.0 Resolution: Fixed > Create schema automatically in the insertion > > > Key: IOTDB-193 > URL: https://issues.apache.org/jira/browse/IOTDB-193 > Project: Apache IoTDB > Issue Type: New Feature >Reporter: Jialin Qiao >Priority: Minor > Labels: pull-request-available > Fix For: 0.9.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Setting storage group and creating time series can be troublesome when using > IoTDB in applications. > Let's look at the typical scenes: > The devices send messages to Kafka. Each message includes: factoryId, > deviceId, timestamp, s1_value, s2_value, s3_value. > The consumer of Kafka needs to consume the messages and organize the data > into an insert statement: "insert into root.factoryId.deviceId(time, s1, s2, > s3) values(timestamp, s1_value, s2_value, s3_value)" > Before inserting the data into IoTDB, the consumer needs to judge whether the > storage group and time series are created before, which is not convenient. > Typically, there are 3 ways to do that: > # Caching the storage group and timeseries created before in the consumer > # Query from IoTDB whether a storage group and timeseries exists > # Directly create metadata regardless of whether created before > Could IoTDB support creating metadata (at least time series) automatically > when receiving an insertion? > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (IOTDB-203) A new result set format
[ https://issues.apache.org/jira/browse/IOTDB-203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jialin Qiao closed IOTDB-203. - Fix Version/s: 0.9.0 Resolution: Fixed > A new result set format > --- > > Key: IOTDB-203 > URL: https://issues.apache.org/jira/browse/IOTDB-203 > Project: Apache IoTDB > Issue Type: New Feature >Reporter: Jialin Qiao >Priority: Minor > Labels: pull-request-available > Fix For: 0.9.0 > > Time Spent: 20m > Remaining Estimate: 0h > > When executing a SQL like "select d1.s1, d2.s1 from root.sg1", the default > result set format in IoTDB is > "time, root.sg1.d1.s1, root.sg1.d2.s1" > 1 , 1, 1 > 2, 2, 2 > However, some users want to get another format, The results could be grouped > by device, then sorted by time. > "time, deviceId, s1". > 1, root.sg1.d1, 1 > 2, root.sg1.d2, 2 > > This can be done in the client, but it would be better if we support this > format in the server. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IOTDB-264) Lake checking datatype before writing WAL
Jialin Qiao created IOTDB-264: - Summary: Lake checking datatype before writing WAL Key: IOTDB-264 URL: https://issues.apache.org/jira/browse/IOTDB-264 Project: Apache IoTDB Issue Type: Bug Affects Versions: 0.8.0 Reporter: Jialin Qiao When execute an InsertPlan, we first check whether the timeseries exists or not. Then we write the InsertPlan to WAL and insert it to memtable. However, if the data type mismatches the registered schema, WAL will still be written but inserting to memtable will fail. When restart IoTDB, the WAL cannot be replayed due to NumberFormatException and IoTDB will fail to restart. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (IOTDB-251) Improve query data structure in RPC
[ https://issues.apache.org/jira/browse/IOTDB-251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jialin Qiao closed IOTDB-251. - Fix Version/s: 0.9.0 Resolution: Fixed > Improve query data structure in RPC > --- > > Key: IOTDB-251 > URL: https://issues.apache.org/jira/browse/IOTDB-251 > Project: Apache IoTDB > Issue Type: Improvement >Reporter: Jialin Qiao >Priority: Major > Labels: pull-request-available > Fix For: 0.9.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Similar to the RowBatch in the write interface, we could use primitive data > arrays in ResultSet in the RPC query, instead of constructing record each > line. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (IOTDB-261) Special characters in Session
[
https://issues.apache.org/jira/browse/IOTDB-261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jialin Qiao closed IOTDB-261.
-
Fix Version/s: 0.9.0
Resolution: Fixed
> Special characters in Session
> -
>
> Key: IOTDB-261
> URL: https://issues.apache.org/jira/browse/IOTDB-261
> Project: Apache IoTDB
> Issue Type: Bug
>Affects Versions: 0.9.0-SNAPSHOT
>Reporter: Jialin Qiao
>Priority: Major
> Labels: pull-request-available
> Fix For: 0.9.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
>
> When using Session to set storage group or create time series, special
> character in the path will cause an error in mlog.txt, which impacts the
> restart and recover of IoTDB.
>
> session.setStorageGroup("root.tur_\n\t_bine");
> session.createTimeseries("root.turbine.d1.s_\n\t_1", TSDataType.INT64,
> TSEncoding.RLE, CompressionType.SNAPPY);
>
> It's better to reject these characters in the Session.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (IOTDB-264) Lake checking datatype before writing WAL
[ https://issues.apache.org/jira/browse/IOTDB-264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jialin Qiao closed IOTDB-264. - Fix Version/s: 0.9.0 Resolution: Fixed > Lake checking datatype before writing WAL > - > > Key: IOTDB-264 > URL: https://issues.apache.org/jira/browse/IOTDB-264 > Project: Apache IoTDB > Issue Type: Bug >Affects Versions: 0.8.0 >Reporter: Jialin Qiao >Priority: Major > Labels: pull-request-available > Fix For: 0.9.0 > > Time Spent: 20m > Remaining Estimate: 0h > > When execute an InsertPlan, we first check whether the timeseries exists or > not. Then we write the InsertPlan to WAL and insert it to memtable. However, > if the data type mismatches the registered schema, WAL will still be written > but inserting to memtable will fail. > > When restart IoTDB, the WAL cannot be replayed due to NumberFormatException > and IoTDB will fail to restart. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (IOTDB-299) Merge ChunkBuffer to ChunkWriterImpl
[ https://issues.apache.org/jira/browse/IOTDB-299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jialin Qiao closed IOTDB-299. - Resolution: Fixed > Merge ChunkBuffer to ChunkWriterImpl > > > Key: IOTDB-299 > URL: https://issues.apache.org/jira/browse/IOTDB-299 > Project: Apache IoTDB > Issue Type: Improvement >Reporter: Jialin Qiao >Priority: Major > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > ChunkBuffer has many fields and functions, which makes it not like a buffer > but like a writer. > Merge it into ChunkWriterImpl will make the write process clearer. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IOTDB-324) Inaccurate Statistics when write batch
Jialin Qiao created IOTDB-324:
-
Summary: Inaccurate Statistics when write batch
Key: IOTDB-324
URL: https://issues.apache.org/jira/browse/IOTDB-324
Project: Apache IoTDB
Issue Type: Bug
Affects Versions: 0.9.0
Reporter: Jialin Qiao
When writing a batch in ChunkWriterImpl, the statistics are updated without
considering the batchSize.
When writing a 100 size array, batch size is 90, the last 10 points is also
calculated in the Statistics.
In ChunkWirterImpl:
```
public void write(long[] timestamps, double[] values, int batchSize) {
this.maxTimestamp = timestamps[batchSize - 1];
valueCountInOnePage += batchSize;
if (minTimestamp == Long.MIN_VALUE) {
minTimestamp = timestamps[0];
}
pageWriter.write(timestamps, values, batchSize);
pageStatistics.updateStats(values); ** this line is not
correct
checkPageSizeAndMayOpenANewPage();
}
```
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IOTDB-325) Refactor Statistics
Jialin Qiao created IOTDB-325: - Summary: Refactor Statistics Key: IOTDB-325 URL: https://issues.apache.org/jira/browse/IOTDB-325 Project: Apache IoTDB Issue Type: Improvement Reporter: Jialin Qiao There are Statistics and StatisticsForFilter in TsFile module, which is in chaos. Also, the ByteBuffer[] in Statistics is useless, as the subclass could serialize and deserialize the fields independently. There is no need to construct a ByteBuffer[] in the parent class. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (IOTDB-279) Merge TsDigest into Statistics
[ https://issues.apache.org/jira/browse/IOTDB-279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jialin Qiao closed IOTDB-279. - Resolution: Fixed > Merge TsDigest into Statistics > -- > > Key: IOTDB-279 > URL: https://issues.apache.org/jira/browse/IOTDB-279 > Project: Apache IoTDB > Issue Type: Improvement >Reporter: Jialin Qiao >Priority: Major > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > As I observe, TsDigest is only the ByteBuffer format of Statistics, so why > not merge them, which could make the code clear. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (IOTDB-284) Do not write empty page
[
https://issues.apache.org/jira/browse/IOTDB-284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jialin Qiao closed IOTDB-284.
-
Fix Version/s: 0.9.0
Resolution: Fixed
> Do not write empty page
> ---
>
> Key: IOTDB-284
> URL: https://issues.apache.org/jira/browse/IOTDB-284
> Project: Apache IoTDB
> Issue Type: Improvement
>Reporter: Jialin Qiao
>Priority: Major
> Fix For: 0.9.0
>
>
> SET STORAGE GROUP TO root.turbine;
> CREATE TIMESERIES root.turbine.d2.s0 WITH DATATYPE=INT32, ENCODING=RLE;
> insert into root.turbine.d2(timestamp,s0) values(2,25.3);
> flush
>
> When receiving the insert statement, IoTDB will create a ChunkWriterImpl, but
> the value will not be inserted because of type error.
> The empty ChunkWriterImpl will be written when meeting the 'flush' command.
> Then, the server will log an error:
>
> 19:33:24.667 [pool-6-IoTDB-Flush-SubTask-ServerServiceImpl-thread-2] ERROR
> org.apache.iotdb.tsfile.write.chunk.ChunkBuffer - Write page error,
> [s0,INT32,RLE,{},UNCOMPRESSED], minTime:-9223372036854775808, maxTime:0
>
> We can check the data type before creating the ChunkWriterImpl to avoid write
> empty ChunkWriterImpl.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (IOTDB-280) Remove ChunkBufferPool
[ https://issues.apache.org/jira/browse/IOTDB-280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jialin Qiao closed IOTDB-280. - Fix Version/s: 0.9.0 Resolution: Fixed > Remove ChunkBufferPool > -- > > Key: IOTDB-280 > URL: https://issues.apache.org/jira/browse/IOTDB-280 > Project: Apache IoTDB > Issue Type: Improvement >Reporter: Jialin Qiao >Priority: Major > Fix For: 0.9.0 > > > ChunkBufferPool has no effect on improving performance, it can be removed for > a clean constructor of ChunkWriterImpl. > ChunkWriterImpl could receive a MeasuremnetSchema and construct a ChunkBuffer > inside. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IOTDB-238) Remove TS_SessionHandle in TSExecuteStatementReq
Jialin Qiao created IOTDB-238: - Summary: Remove TS_SessionHandle in TSExecuteStatementReq Key: IOTDB-238 URL: https://issues.apache.org/jira/browse/IOTDB-238 Project: Apache IoTDB Issue Type: Improvement Reporter: Jialin Qiao When we execute a sql statement, the client sends a TSExecuteStatementReq to the server. The TSExecuteStatementReq includes a TS_SessionHandle and a sql in String. However, the TS_SessionHandle has never been used. We can remove this. Then, the TSExecuteStatementReq struct can be simplified to a string. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (IOTDB-180) Get rid of JSON format in "show timeseries"
[ https://issues.apache.org/jira/browse/IOTDB-180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jialin Qiao closed IOTDB-180. - Fix Version/s: 0.9.0 Resolution: Fixed > Get rid of JSON format in "show timeseries" > --- > > Key: IOTDB-180 > URL: https://issues.apache.org/jira/browse/IOTDB-180 > Project: Apache IoTDB > Issue Type: Wish >Reporter: Jialin Qiao >Priority: Minor > Labels: pull-request-available > Fix For: 0.9.0 > > Attachments: image-2019-08-27-09-56-20-654.png, > image-2019-08-27-09-56-28-577.png > > Time Spent: 20m > Remaining Estimate: 0h > > Currently, "show timeseries" prints result in JSON format, which is not > friendly compared to "show timeseries root" in table format. > !image-2019-08-27-09-56-20-654.png|width=463,height=538! > !image-2019-08-27-09-56-28-577.png|width=694,height=458! > Intuitively, I would expect that "show timeseries" works as "show timeseries > root". > Therefore, when users input a "show timeseries", I suggest that we treat it > as "show timeseries root" and print results in table format. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (IOTDB-98) Batch insertion in Server
[ https://issues.apache.org/jira/browse/IOTDB-98?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jialin Qiao closed IOTDB-98. Resolution: Done > Batch insertion in Server > - > > Key: IOTDB-98 > URL: https://issues.apache.org/jira/browse/IOTDB-98 > Project: Apache IoTDB > Issue Type: Improvement >Reporter: Jialin Qiao >Priority: Minor > > Currently, when the client sends a batch of statements (insert/delete) to the > server, the server will get each statement from the batch and execute one by > one. For each statement, the corresponding FileNodeProcessor (for a storage > group) will get a write lock and then execute the statement, which causes > unnecessary lock contention. > It can be improved by getting a write lock once and executing a batch of > statements. We can first consider the scenario that the statements in a batch > are all insertions. > The new process mainly contains 3 steps: > (1) Group the insert statement by storage group while retaining the original > order in the batch. > (2) For each storage group, get the write lock and execute all statements > belong to it. > (3) Set the return code of each statement to the origin position in the batch. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (IOTDB-191) Enrich Session interfaces
[ https://issues.apache.org/jira/browse/IOTDB-191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jialin Qiao closed IOTDB-191. - Fix Version/s: 0.9.0 Resolution: Fixed > Enrich Session interfaces > - > > Key: IOTDB-191 > URL: https://issues.apache.org/jira/browse/IOTDB-191 > Project: Apache IoTDB > Issue Type: New Feature >Reporter: Jialin Qiao >Priority: Minor > Labels: pull-request-available > Fix For: 0.9.0 > > Time Spent: 20m > Remaining Estimate: 0h > > The module "Session" is an RPC interface for users, which is more efficient > than JDBC. > Currently, it only has 3 interfaces: (1) ser storage group (2) create time > series (3) insert batch. > Other interfaces such as delete time series, the query could be added. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IOTDB-251) Improve query data structure in RPC
Jialin Qiao created IOTDB-251: - Summary: Improve query data structure in RPC Key: IOTDB-251 URL: https://issues.apache.org/jira/browse/IOTDB-251 Project: Apache IoTDB Issue Type: Improvement Reporter: Jialin Qiao Similar to the RowBatch in the write interface, we could use primitive data arrays in ResultSet in the RPC query, instead of constructing record each line. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (IOTDB-320) [Travis] [WinOS] [ERROR] OS=Windows and the assembly descriptor contains a *nix-specific root-relative-reference (starting with slash) /
[ https://issues.apache.org/jira/browse/IOTDB-320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jialin Qiao closed IOTDB-320. - Resolution: Fixed > [Travis] [WinOS] [ERROR] OS=Windows and the assembly descriptor contains a > *nix-specific root-relative-reference (starting with slash) / > > > Key: IOTDB-320 > URL: https://issues.apache.org/jira/browse/IOTDB-320 > Project: Apache IoTDB > Issue Type: Bug >Reporter: xiangdong Huang >Priority: Major > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > Travis for WinOS has the following error: > > > [INFO] > > 1736[INFO] --- maven-assembly-plugin:3.0.0:single (server-assembly) @ > iotdb-server --- > > 1737[INFO] Reading assembly descriptor: src/assembly/server.xml > > 1738[ERROR] OS=Windows and the assembly descriptor contains a *nix-specific > root-relative-reference (starting with slash) / > > 1739[INFO] Copying files to > C:\Users\travis\build\apache\incubator-iotdb\server\target\iotdb-server-0.9.1-SNAPSHOT > > 1740[WARNING] Assembly file: > C:\Users\travis\build\apache\incubator-iotdb\server\target\iotdb-server-0.9.1-SNAPSHOT > is not a regular file (it may be a directory). It cannot be attached to the > project build for installation or deployment. > > 1741[ERROR] OS=Windows and the assembly descriptor contains a *nix-specific > root-relative-reference (starting with slash) / > > 1742[INFO] Building zip: > C:\Users\travis\build\apache\incubator-iotdb\server\target\iotdb-server-0.9.1-SNAPSHOT.zip > > 1743[INFO] > > 1744[INFO] --- maven-failsafe-plugin:2.22.0:integration-test > (run-integration-tests) @ iotdb-server --- > > 1745[INFO] > > > [https://travis-ci.org/apache/incubator-iotdb/jobs/615886573] > It may because / is incorrect for Win users. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (IOTDB-375) Bug in parameter adapter
[ https://issues.apache.org/jira/browse/IOTDB-375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jialin Qiao closed IOTDB-375. - Fix Version/s: 0.10.0-SNAPSHOT Resolution: Fixed > Bug in parameter adapter > > > Key: IOTDB-375 > URL: https://issues.apache.org/jira/browse/IOTDB-375 > Project: Apache IoTDB > Issue Type: Bug >Affects Versions: 0.9.0, 0.10.0-SNAPSHOT >Reporter: Jialin Qiao >Assignee: Tianan Li >Priority: Major > Labels: pull-request-available > Fix For: 0.10.0-SNAPSHOT > > Time Spent: 10m > Remaining Estimate: 0h > > I set enable_parameter_adapter to true and use the default memory setting. > > After starting IoTDB, I set one storage group root.sg1 and create timeseries, > the service rejects the creating after 66777 is created. However, the log > only says that "IoTDB system load is too large to add timeseries". We could > hint more, such as increase memory or disable the enable_parameter_adapter in > iotdb-engine.properties. > > Then, I execute delete storage group root.sg1 and redo the above operations. > > This time, only 34988 was successfully created. (This is the bug, we should > be able to create 66777 timeseries again) > > After restart IoTDB, it recalculates the timeseries one-by-one and prints a > lot of debug logs. I suggest accepting the register without checking > parameters because it is already checked before. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (IOTDB-293) Variable naming convention
[ https://issues.apache.org/jira/browse/IOTDB-293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jialin Qiao closed IOTDB-293. - Fix Version/s: (was: 0.8.0) Resolution: Fixed > Variable naming convention > -- > > Key: IOTDB-293 > URL: https://issues.apache.org/jira/browse/IOTDB-293 > Project: Apache IoTDB > Issue Type: Improvement >Reporter: francisdu >Priority: Critical > Labels: pull-request-available, variable > Fix For: 0.9.0 > > Original Estimate: 2h > Time Spent: 40m > Remaining Estimate: 1h 20m > > I think Scala should follow the variable naming convention in Java.PM should > do code review.[spark-iotdb-connector] : > [https://github.com/apache/incubator-iotdb/blob/bd2992438208a6c2379848cd4224ac04bdd475d1/spark-iotdb-connector/src/main/scala/org/apache/iotdb/spark/db/Transformer.scala#L95] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (IOTDB-364) Add IoTDBDataDirViewer Tool
[ https://issues.apache.org/jira/browse/IOTDB-364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jialin Qiao closed IOTDB-364. - Resolution: Fixed > Add IoTDBDataDirViewer Tool > --- > > Key: IOTDB-364 > URL: https://issues.apache.org/jira/browse/IOTDB-364 > Project: Apache IoTDB > Issue Type: New Feature >Reporter: Lei Rui >Assignee: Lei Rui >Priority: Major > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > To have a quick overview of the data distribution in the data directories -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (IOTDB-345) upgrade thrift from 0.12 to 0.13
[ https://issues.apache.org/jira/browse/IOTDB-345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jialin Qiao closed IOTDB-345. - Fix Version/s: 0.10.0-SNAPSHOT Resolution: Fixed > upgrade thrift from 0.12 to 0.13 > > > Key: IOTDB-345 > URL: https://issues.apache.org/jira/browse/IOTDB-345 > Project: Apache IoTDB > Issue Type: Bug >Reporter: xiangdong Huang >Assignee: xiangdong Huang >Priority: Major > Labels: easy-fix, pull-request-available > Fix For: 0.10.0-SNAPSHOT > > Time Spent: 20m > Remaining Estimate: 0h > > It seems thrift 0.12 has a bug that when a connection is clsoed, an exception > is printed on the server side. > And, if you install thrift dependency using `pip`, you can not find the 0.12 > version. Only 0.13.0 exists. > > So, it is good to upgrade it to 0.13 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (IOTDB-370) v0.10.0 JDBC Concurrent Error
[ https://issues.apache.org/jira/browse/IOTDB-370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jialin Qiao closed IOTDB-370. - Resolution: Fixed > v0.10.0 JDBC Concurrent Error > - > > Key: IOTDB-370 > URL: https://issues.apache.org/jira/browse/IOTDB-370 > Project: Apache IoTDB > Issue Type: Bug >Affects Versions: 0.10.0-SNAPSHOT >Reporter: Rui Liu >Priority: Major > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > When using iotdb-benchmark dev branch to test IoTDB v0.10.0-SNAPSHOT, using > the JDBC API including executeBatch() and execute() to do data ingestion. The > following error will occur: > In the benchmark log: > ``` > 2019-12-16 11:03:36,825 ERROR > cn.edu.tsinghua.iotdb.benchmark.tsdb.DBWrapper:73 - Insert batch failed > because > java.sql.SQLException: Fail to execute batch sqls after reconnecting. please > check server status > at org.apache.iotdb.jdbc.IoTDBStatement.executeBatch(IoTDBStatement.java:349) > at > cn.edu.tsinghua.iotdb.benchmark.tsdb.iotdb.IoTDB.insertOneBatch(IoTDB.java:141) > at > cn.edu.tsinghua.iotdb.benchmark.tsdb.DBWrapper.insertOneBatch(DBWrapper.java:54) > at > cn.edu.tsinghua.iotdb.benchmark.client.BaseClient.doTest(BaseClient.java:65) > at cn.edu.tsinghua.iotdb.benchmark.client.Client.run(Client.java:44) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at java.lang.Thread.run(Thread.java:748) > Caused by: org.apache.thrift.TApplicationException: Internal error processing > executeBatchStatement > at org.apache.thrift.TServiceClient.receiveBase(TServiceClient.java:79) > at > org.apache.iotdb.service.rpc.thrift.TSIService$Client.recv_executeBatchStatement(TSIService.java:230) > at > org.apache.iotdb.service.rpc.thrift.TSIService$Client.executeBatchStatement(TSIService.java:217) > at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.apache.iotdb.rpc.SynchronizedHandler.invoke(SynchronizedHandler.java:39) > at com.sun.proxy.$Proxy5.executeBatchStatement(Unknown Source) > at > org.apache.iotdb.jdbc.IoTDBStatement.executeBatchSQL(IoTDBStatement.java:363) > at org.apache.iotdb.jdbc.IoTDBStatement.executeBatch(IoTDBStatement.java:347) > ... 9 common frames omitted > ``` > > In the IoTDB log: > ``` > 2019-12-16 11:12:04,154 [pool-2-IoTDB-JDBC-Client-thread-22] ERROR > org.apache.thrift.ProcessFunction:47 - Internal error processing > executeBatchStatement > java.lang.NullPointerException: null > at > org.apache.iotdb.db.qp.physical.crud.InsertPlan.getPaths(InsertPlan.java:98) > at > org.apache.iotdb.db.service.TSServiceImpl.checkAuthority(TSServiceImpl.java:1347) > at > org.apache.iotdb.db.service.TSServiceImpl.executeUpdateStatement(TSServiceImpl.java:960) > at > org.apache.iotdb.db.service.TSServiceImpl.executeStatementInBatch(TSServiceImpl.java:506) > at > org.apache.iotdb.db.service.TSServiceImpl.executeBatchStatement(TSServiceImpl.java:482) > at > org.apache.iotdb.service.rpc.thrift.TSIService$Processor$executeBatchStatement.getResult(TSIService.java:1718) > at > org.apache.iotdb.service.rpc.thrift.TSIService$Processor$executeBatchStatement.getResult(TSIService.java:1698) > at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:38) > at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:38) > at > org.apache.thrift.server.TThreadPoolServer$WorkerProcess.run(TThreadPoolServer.java:313) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at java.lang.Thread.run(Thread.java:748) > ``` > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (IOTDB-366) Concurrent Error when multiple JDBC client send queries
[
https://issues.apache.org/jira/browse/IOTDB-366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jialin Qiao closed IOTDB-366.
-
Resolution: Fixed
> Concurrent Error when multiple JDBC client send queries
> ---
>
> Key: IOTDB-366
> URL: https://issues.apache.org/jira/browse/IOTDB-366
> Project: Apache IoTDB
> Issue Type: Bug
>Affects Versions: 0.10.0-SNAPSHOT
>Reporter: Xiangdong Huang
>Priority: Major
>
> HI,
> After the SQL parser is upgraded to Antlr4, seems a concurrent error is
> introduce.
> The error can be reproduced by:
> In org.apache.iotdb.db.integration.IoTDBQueryDemoIT class, add a new test
> function:
> {code:java}
> // code placeholder
> @Test
> public void testConcurrent() {
> new Thread(new Runnable() {
> @Override
> public void run() {
> try {
> selectTest();
> } catch (Exception e) {
> e.printStackTrace();
> }
> }
> }).start();
> new Thread(new Runnable() {
> @Override
> public void run() {
> try {
> selectTest();
> } catch (Exception e) {
> e.printStackTrace();
> }
> }
> }).start();
> }
> {code}
>
> Notice, because it is a concurrent error, the issue is not reproduced every
> time.
> And, the exceptions in the above test function can not be caught by Junit,
> so it is not a formal UT code.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (IOTDB-283) Modify rules of datatype inference when creating schema automatically is enabled
[ https://issues.apache.org/jira/browse/IOTDB-283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jialin Qiao closed IOTDB-283. - Fix Version/s: 0.9.0 Resolution: Fixed > Modify rules of datatype inference when creating schema automatically is > enabled > > > Key: IOTDB-283 > URL: https://issues.apache.org/jira/browse/IOTDB-283 > Project: Apache IoTDB > Issue Type: Bug >Reporter: Yanzhe An >Priority: Major > Labels: pull-request-available > Fix For: 0.9.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Rules of datatype inference are unsuitable for batch insertions when creating > schema automatically is enabled, because _BatchInsertPlan_ has a member > variable named _dataTypes_ which indicates datatypes of each row. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (IOTDB-217) A new predicate of time
[ https://issues.apache.org/jira/browse/IOTDB-217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jialin Qiao closed IOTDB-217. - Fix Version/s: 0.10.0-SNAPSHOT Resolution: Fixed > A new predicate of time > --- > > Key: IOTDB-217 > URL: https://issues.apache.org/jira/browse/IOTDB-217 > Project: Apache IoTDB > Issue Type: New Feature >Reporter: Jialin Qiao >Priority: Major > Labels: medium, pull-request-available > Fix For: 0.10.0-SNAPSHOT > > Time Spent: 20m > Remaining Estimate: 0h > > I have encountered an issue that our SQL cannot support well. > The scenario is: I want to get the data between 9:00am to 12:00am in each day > last week. > Could we add a new sql to do that? The sql maybe like this: > > select s0 from root.d0 where time >= now()-1week and time <= now() groupby > time(1d) innerInterval(9h, 12h) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (IOTDB-343) Test method in session to help user to analyze time cost
[ https://issues.apache.org/jira/browse/IOTDB-343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jialin Qiao closed IOTDB-343. - Resolution: Fixed > Test method in session to help user to analyze time cost > > > Key: IOTDB-343 > URL: https://issues.apache.org/jira/browse/IOTDB-343 > Project: Apache IoTDB > Issue Type: New Feature >Reporter: Kaifeng Xue >Priority: Major > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > In our users' scenery, them often preprocess raw data into insert request and > then insert to IOTDB. We should support them to analyze the preprocessing > time and our database's executing time. So we should add test method in > session. In these test method, server just return success without handling > requests. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (IOTDB-282) require "show version" query
[ https://issues.apache.org/jira/browse/IOTDB-282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jialin Qiao closed IOTDB-282. - Fix Version/s: (was: 0.8.0) 0.9.0 Resolution: Fixed > require "show version" query > > > Key: IOTDB-282 > URL: https://issues.apache.org/jira/browse/IOTDB-282 > Project: Apache IoTDB > Issue Type: New Feature >Reporter: Yingbo >Priority: Major > Labels: pull-request-available > Fix For: 0.9.0 > > Time Spent: 1h > Remaining Estimate: 0h > > in order to support different iotdb versions in different production > environment. the data access program needs a "show version" or "show > parameters" query. so as to use compatible query syntax accordingly. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (IOTDB-371) [TravisCI] Fix maven version on WinOS.
[ https://issues.apache.org/jira/browse/IOTDB-371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jialin Qiao closed IOTDB-371. - Fix Version/s: 0.10.0-SNAPSHOT Resolution: Fixed [https://github.com/apache/incubator-iotdb/pull/650] > [TravisCI] Fix maven version on WinOS. > --- > > Key: IOTDB-371 > URL: https://issues.apache.org/jira/browse/IOTDB-371 > Project: Apache IoTDB > Issue Type: Bug >Reporter: Xiangdong Huang >Assignee: Jialin Qiao >Priority: Major > Labels: easy-fix, travis-ci > Fix For: 0.10.0-SNAPSHOT > > > Maven 3.6.2 has removed from > [https://www-eu.apache.org/dist/maven/maven-3/3.6.2/binaries/apache-maven-3.6.2-bin.zip] > , which will lead to the travis ci failure for WinOS. > Modify .travis.yml file and upgrade the download link to 3.6.3 can solve the > problem. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (IOTDB-346) StorageGroupProcessor.sequenceFileList is ordered by fileName rather than dataTime
[
https://issues.apache.org/jira/browse/IOTDB-346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jialin Qiao closed IOTDB-346.
-
Fix Version/s: 0.10.0-SNAPSHOT
Resolution: Fixed
> StorageGroupProcessor.sequenceFileList is ordered by fileName rather than
> dataTime
> --
>
> Key: IOTDB-346
> URL: https://issues.apache.org/jira/browse/IOTDB-346
> Project: Apache IoTDB
> Issue Type: Bug
>Reporter: Lei Rui
>Assignee: Tianan Li
>Priority: Major
> Labels: pull-request-available
> Fix For: 0.10.0-SNAPSHOT
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> `StorageGroupProcessor.sequenceFileList` is ordered by fileName rather than
> by time of data, as reflected in the `StorageGroupProcessor.getAllFiles`
> method code:
> {code:java}
> tsFiles.sort(this::compareFileName);
> {code}
>
> I use the following examples to expose the bug when the order of fileName is
> inconsistent with that of dataTime.
> First, for preparation, I created three tsfiles using the following sql:
> {code:java}
> SET STORAGE GROUP TO root.ln.wf01.wt01
> CREATE TIMESERIES root.ln.wf01.wt01.status WITH DATATYPE=BOOLEAN,
> ENCODING=PLAIN
> CREATE TIMESERIES root.ln.wf01.wt01.temperature WITH DATATYPE=DOUBLE,
> ENCODING=PLAIN
> CREATE TIMESERIES root.ln.wf01.wt01.hardware WITH DATATYPE=INT32,
> ENCODING=PLAIN
> INSERT INTO root.ln.wf01.wt01(timestamp,temperature,status, hardware)
> values(1, 1.1, false, 11)
> INSERT INTO root.ln.wf01.wt01(timestamp,temperature,status, hardware)
> values(2, 2.2, true, 22)
> INSERT INTO root.ln.wf01.wt01(timestamp,temperature,status, hardware)
> values(3, 3.3, false, 33)
> INSERT INTO root.ln.wf01.wt01(timestamp,temperature,status, hardware)
> values(4, 4.4, false, 44)
> INSERT INTO root.ln.wf01.wt01(timestamp,temperature,status, hardware)
> values(5, 5.5, false, 55)
> flush
> INSERT INTO root.ln.wf01.wt01(timestamp,temperature,status, hardware)
> values(100, 100.1, false, 110)
> INSERT INTO root.ln.wf01.wt01(timestamp,temperature,status, hardware)
> values(150, 200.2, true, 220)
> INSERT INTO root.ln.wf01.wt01(timestamp,temperature,status, hardware)
> values(200, 300.3, false, 330)
> INSERT INTO root.ln.wf01.wt01(timestamp,temperature,status, hardware)
> values(250, 400.4, false, 440)
> INSERT INTO root.ln.wf01.wt01(timestamp,temperature,status, hardware)
> values(300, 500.5, false, 550)
> flush
> INSERT INTO root.ln.wf01.wt01(timestamp,temperature,status, hardware)
> values(10, 10.1, false, 110)
> INSERT INTO root.ln.wf01.wt01(timestamp,temperature,status, hardware)
> values(20, 20.2, true, 220)
> INSERT INTO root.ln.wf01.wt01(timestamp,temperature,status, hardware)
> values(30, 30.3, false, 330)
> INSERT INTO root.ln.wf01.wt01(timestamp,temperature,status, hardware)
> values(40, 40.4, false, 440)
> INSERT INTO root.ln.wf01.wt01(timestamp,temperature,status, hardware)
> values(50, 50.5, false, 550)
> flush
> {code}
> The tsfiles created are organized in the following directory structure:
> {code:java}
> |data
> |--sequence
> |root.ln.wf01.wt01
> |--1575813520203-101-0.tsfile
> |--1575813520203-101-0.tsfile.resource
> |--1575813520669-103-0.tsfile
> |--1575813520669-103-0.tsfile.resource
> |--unsequence
> |root.ln.wf01.wt01
> |--1575813521063-105-0.tsfile
> |--1575813521063-105-0.tsfile.resource
> {code}
> ||File Name||Data Time||
> |(a) 1575813520203-101-0.tsfile|1-5|
> |(c) 1575813521063-105-0.tsfile|10-50|
> |(b) 1575813520669-103-0.tsfile|100-300|
> Note how the order of fileName is inconsistent with that of dataTime.
> By the way, if you look into the code, you will know how the file name is
> generated:
> {code:java}
> System.currentTimeMillis() + IoTDBConstant.TSFILE_NAME_SEPARATOR +
> versionController.nextVersion() + IoTDBConstant.TSFILE_NAME_SEPARATOR + "0" +
> TSFILE_SUFFIX
> {code}
>
> Then, I loaded the three tsfiles into another brand new IoTDB. I did two
> experiments with different loading orders each.
> In the first experiment, the tsfiles were loaded in their data time order.
> That is,
> {code:java}
> IoTDB> load 1575813520203-101-0.tsfile // tsfile (a), with data time 1-5
> IoTDB> load 1575813521063-105-0.tsfile // tsfile (c), with data time 10-50
> IoTDB> load 1575813520669-103-0.tsfile // tsfile (b), with data time
> 100-300{code}
> After loading successfully, I did the following query in the same client
> window and got the wrong result:
> {code:java}
> IoTDB> select * from root
> +---+-+-+-+
> | Time|root.ln.wf01.wt01.temperature|
> root.ln.wf01.wt01.status| root.ln.wf01.wt01.hardware|
>
[jira] [Closed] (IOTDB-14) Concurrent Error of HashMap in StatMonitor class
[ https://issues.apache.org/jira/browse/IOTDB-14?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jialin Qiao closed IOTDB-14. Resolution: Cannot Reproduce > Concurrent Error of HashMap in StatMonitor class > > > Key: IOTDB-14 > URL: https://issues.apache.org/jira/browse/IOTDB-14 > Project: Apache IoTDB > Issue Type: Bug >Reporter: xiangdong Huang >Assignee: Rui Liu >Priority: Major > Labels: need-to-check > > When running IoTDB UT, I found an exception: > [INFO] Running org.apache.iotdb.db.monitor.MonitorTest > WARN [2019-01-28 23:50:28,816] [main] > org.apache.iotdb.db.conf.IoTDBDescriptor:60 - Cannot find IOTDB_HOME or > IOTDB_CONF environment variable when loading config file > iotdb-engine.properties, use default configuration > INFO [2019-01-28 23:50:28,822] [main] > org.apache.iotdb.db.conf.directories.Directories:66 - folder > data/data/settled in tsfileFolders doesn't exist, create it > WARN [2019-01-28 23:50:28,823] [main] > org.apache.iotdb.tsfile.common.conf.TSFileDescriptor:88 - Failed to find > config file tsfile-format.properties at classpath, use default configuration > INFO [2019-01-28 23:50:28,834] [main] > org.apache.iotdb.db.auth.user.BasicUserManager:76 - Admin initialized > INFO [2019-01-28 23:50:28,836] [main] > org.apache.iotdb.db.auth.user.BasicUserManager:76 - Admin initialized > INFO [2019-01-28 23:50:28,838] [main] > org.apache.iotdb.db.auth.authorizer.BasicAuthorizer:62 - Initialization of > Authorizer completes > INFO [2019-01-28 23:50:28,840] [main] > org.apache.iotdb.db.auth.user.BasicUserManager:76 - Admin initialized > INFO [2019-01-28 23:50:28,841] [main] > org.apache.iotdb.db.auth.authorizer.BasicAuthorizer:62 - Initialization of > Authorizer completes > INFO [2019-01-28 23:50:28,844] [main] > org.apache.iotdb.db.engine.filenode.FileNodeManager:113 - data/system/info > dir home doesn't exist, create it > INFO [2019-01-28 23:50:29,866] > [pool-1-IoTDB-StatMonitor-ServerServiceImpl-thread-1] > org.apache.iotdb.db.engine.filenode.FileNodeProcessor:221 - The data > directory of the filenode processor root.stats doesn't exist. Create new > directory data/system/info/root.stats > INFO [2019-01-28 23:50:29,876] > [pool-1-IoTDB-StatMonitor-ServerServiceImpl-thread-1] > org.apache.iotdb.db.engine.filenode.FileNodeProcessor:498 - Allocate folder > data/data/settled for the new bufferwrite processor. > ERROR [2019-01-28 23:50:33,855] > [pool-1-IoTDB-StatMonitor-ServerServiceImpl-thread-1] > org.apache.iotdb.db.monitor.StatMonitor$statBackLoop:376 - Error occurred in > Stat Monitor thread > java.util.ConcurrentModificationException: null > at java.util.HashMap$HashIterator.nextNode(HashMap.java:1437) > at java.util.HashMap$EntryIterator.next(HashMap.java:1471) > at java.util.HashMap$EntryIterator.next(HashMap.java:1469) > at > org.apache.iotdb.db.monitor.StatMonitor.gatherStatistics(StatMonitor.java:264) > at > org.apache.iotdb.db.monitor.StatMonitor$statBackLoop.run(StatMonitor.java:372) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at java.lang.Thread.run(Thread.java:748) > > It is because when you traverse a HashMap, the elements changed, I think. > > A strange thing is that org.apache.iotdb.db.monitor.MonitorTest passed... It > is what we must fix, otherwise UT is meaningless. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (IOTDB-307) Remove maxTombstoneTime in ChunkHeader
[ https://issues.apache.org/jira/browse/IOTDB-307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jialin Qiao closed IOTDB-307. - Fix Version/s: 0.10.0-SNAPSHOT Resolution: Fixed [https://github.com/apache/incubator-iotdb/pull/587] > Remove maxTombstoneTime in ChunkHeader > -- > > Key: IOTDB-307 > URL: https://issues.apache.org/jira/browse/IOTDB-307 > Project: Apache IoTDB > Issue Type: Improvement >Reporter: atoildw >Priority: Major > Fix For: 0.10.0-SNAPSHOT > > > There is a global variable *maxTombstoneTime* in the ChunkHeader, but when I > check it, it seems like is no longer used anywhere and is always assigned to > 0 in TsFile. I feel the need to remove it to keep code clean. > And need to update the document first。 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (IOTDB-336) Binary files incompatible between JDK8 and JDK11
[ https://issues.apache.org/jira/browse/IOTDB-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jialin Qiao closed IOTDB-336. - Fix Version/s: 0.10.0-SNAPSHOT Resolution: Fixed > Binary files incompatible between JDK8 and JDK11 > > > Key: IOTDB-336 > URL: https://issues.apache.org/jira/browse/IOTDB-336 > Project: Apache IoTDB > Issue Type: Bug >Reporter: xiangdong Huang >Priority: Major > Labels: pull-request-available > Fix For: 0.10.0-SNAPSHOT > > Time Spent: 20m > Remaining Estimate: 0h > > I tried to use JDK11 to compile a binary file, you can get it at > [https://dist.apache.org/repos/dist/dev/incubator/iotdb/0.8.2/rc1]. > However, if a user uses JDK8 to run it, an exception will occur: > java.lang.NoSuchMethodError: java.nio.ByteBuffer.clear()Ljava/nio/ByteBuffer; > > It is because before JDK9, ByteBuffer.clear() returns Buffer, while from > JDK9 on, the method return ByteBuffer. > > According to [https://github.com/apache/curator/pull/312], add a parameter > `–release 8` can solve the problem. > In maven, we can add a property called > ``` > 8 > ``` > I am verifying the solution now. > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (IOTDB-288) Unclear error message notification for "creating timeserie" clause
[ https://issues.apache.org/jira/browse/IOTDB-288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jialin Qiao closed IOTDB-288. - Fix Version/s: 0.9.0 Resolution: Fixed > Unclear error message notification for "creating timeserie" clause > -- > > Key: IOTDB-288 > URL: https://issues.apache.org/jira/browse/IOTDB-288 > Project: Apache IoTDB > Issue Type: Bug >Reporter: xiangdong Huang >Priority: Major > Labels: pull-request-available > Fix For: 0.9.0 > > Time Spent: 20m > Remaining Estimate: 0h > > While I am trying to create a time series whose sensor name is > "RANDOM/foo:BYTE", the create timeseries clause failed, because we do not > support the characters of "/" and ":" in a path. > However, I can not get the above info, the error message (on the client side) > just says: > Meet error while parsing SQL: Statement format is not right: parsing > error,statement: CREATE TIMESERIES root.mi.d1.RANDOM_foo:BYTE WITH > DATATYPE=INT32, ENCODING=RLE. > > While on the server side, you can find the error info: > Caused by: org.apache.iotdb.db.sql.parse.ParseException: line 1:39 character > ':' not supported here > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (IOTDB-308) jdk error when using Travis + Windows
[ https://issues.apache.org/jira/browse/IOTDB-308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jialin Qiao closed IOTDB-308. - Resolution: Fixed > jdk error when using Travis + Windows > - > > Key: IOTDB-308 > URL: https://issues.apache.org/jira/browse/IOTDB-308 > Project: Apache IoTDB > Issue Type: Bug >Reporter: xiangdong Huang >Priority: Major > Labels: pull-request-available > Attachments: image-2019-11-18-22-09-34-671.png > > Time Spent: 20m > Remaining Estimate: 0h > > Sometime travis may failed on WinOS because of: > !image-2019-11-18-22-09-34-671.png! > It is a quite strange exception. The only thing I can do is change a new > JDK.. So, I tried to download jdk zip file manually. > > And, in many cases, travis on WinOS will be timeout, which is als needed to > be fixed. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (IOTDB-319) java deadlock (not sure how to reproduce)
[ https://issues.apache.org/jira/browse/IOTDB-319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jialin Qiao closed IOTDB-319. - Fix Version/s: 0.9.0 Resolution: Fixed > java deadlock (not sure how to reproduce) > - > > Key: IOTDB-319 > URL: https://issues.apache.org/jira/browse/IOTDB-319 > Project: Apache IoTDB > Issue Type: Bug >Affects Versions: 0.9.0 >Reporter: xiangdong Huang >Priority: Major > Labels: hard, pull-request-available > Fix For: 0.9.0 > > Attachments: deadlock.out > > Time Spent: 20m > Remaining Estimate: 0h > > Hi, > my colleague gives me an IoTDB instance which has no response for "select " > SQL. > (but for Schema query sql, it works). > I used jstack to check the process and find a deadlock, you can get the > detailed info in the attachment. > > Found one Java-level deadlock: > = > "pool-2-IoTDB-JDBC-Client-thread-16": > waiting to lock monitor 0x7fdab800ff68 (object 0x0003c7163218, a > org.apache.iotdb.db.query.control.FileReaderManager), > which is held by "pool-2-IoTDB-JDBC-Client-thread-3" > "pool-2-IoTDB-JDBC-Client-thread-3": > waiting for ownable synchronizer 0x0003c6106f40, (a > java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync), > which is held by "MergeThread-0" > "MergeThread-0": > waiting to lock monitor 0x7fdab800ff68 (object 0x0003c7163218, a > org.apache.iotdb.db.query.control.FileReaderManager), > which is held by "pool-2-IoTDB-JDBC-Client-thread-3" > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IOTDB-375) Bug in parameter adapter
Jialin Qiao created IOTDB-375: - Summary: Bug in parameter adapter Key: IOTDB-375 URL: https://issues.apache.org/jira/browse/IOTDB-375 Project: Apache IoTDB Issue Type: Bug Affects Versions: 0.9.0, 0.10.0-SNAPSHOT Reporter: Jialin Qiao I set enable_parameter_adapter to true and use the default memory setting. After starting IoTDB, I set one storage group root.sg1 and create timeseries, the service rejects the creating after 66777 is created. However, the log only says that "IoTDB system load is too large to add timeseries". We could hint more, such as increase memory or disable the enable_parameter_adapter in iotdb-engine.properties. Then, I execute delete storage group root.sg1 and redo the above operations. This time, only 34988 was successfully created. (This is the bug, we should be able to create 66777 timeseries again) After restart IoTDB, it recalculates the timeseries one-by-one and prints a lot of debug logs. I suggest accepting the register without checking parameters because it is already checked before. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IOTDB-356) NullPointerException in ActiveTimeSeriesCounter
Jialin Qiao created IOTDB-356:
-
Summary: NullPointerException in ActiveTimeSeriesCounter
Key: IOTDB-356
URL: https://issues.apache.org/jira/browse/IOTDB-356
Project: Apache IoTDB
Issue Type: Bug
Reporter: Jialin Qiao
Start a empty IoTDB, execute 3 sql:
{code:java}
SET STORAGE GROUP TO root.turbine;
CREATE TIMESERIES root.turbine.d2.s0 WITH DATATYPE=DOUBLE, ENCODING=GORILLA;
insert into root.turbine.d2(timestamp,s0) values(2,25.3);{code}
Kill the server and restart, then you will see:
{code:java}
11:37:45.157 [pool-1-IoTDB-Recovery-Thread-Pool-thread-1] ERROR
org.apache.iotdb.db.conf.adapter.ActiveTimeSeriesCounter - Storage group
root.turbine- registers active time series root.turbine.d2.s0
failed11:37:45.157 [pool-1-IoTDB-Recovery-Thread-Pool-thread-1] ERROR
org.apache.iotdb.db.conf.adapter.ActiveTimeSeriesCounter - Storage group
root.turbine- registers active time series root.turbine.d2.s0
failedjava.lang.NullPointerException: null at
org.apache.iotdb.db.conf.adapter.ActiveTimeSeriesCounter.offer(ActiveTimeSeriesCounter.java:65)
at
org.apache.iotdb.db.engine.flush.MemTableFlushTask.syncFlushMemTable(MemTableFlushTask.java:87)
at
org.apache.iotdb.db.writelog.recover.TsFileRecoverPerformer.redoLogs(TsFileRecoverPerformer.java:213)
at
org.apache.iotdb.db.writelog.recover.TsFileRecoverPerformer.recover(TsFileRecoverPerformer.java:143)
at
org.apache.iotdb.db.engine.storagegroup.StorageGroupProcessor.recoverSeqFiles(StorageGroupProcessor.java:294)
at
org.apache.iotdb.db.engine.storagegroup.StorageGroupProcessor.recover(StorageGroupProcessor.java:223)
at
org.apache.iotdb.db.engine.storagegroup.StorageGroupProcessor.(StorageGroupProcessor.java:210)
at
org.apache.iotdb.db.engine.StorageEngine.lambda$new$0(StorageEngine.java:119)
at java.util.concurrent.FutureTask.run(FutureTask.java:266) at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)11:37:45.158
[pool-1-IoTDB-Recovery-Thread-Pool-thread-1] ERROR
org.apache.iotdb.db.conf.adapter.ActiveTimeSeriesCounter - Update root.turbine-
active ratio failedjava.lang.NullPointerException: null at
org.apache.iotdb.db.conf.adapter.ActiveTimeSeriesCounter.updateActiveRatio(ActiveTimeSeriesCounter.java:79)
at
org.apache.iotdb.db.engine.flush.MemTableFlushTask.syncFlushMemTable(MemTableFlushTask.java:91)
at
org.apache.iotdb.db.writelog.recover.TsFileRecoverPerformer.redoLogs(TsFileRecoverPerformer.java:213)
at
org.apache.iotdb.db.writelog.recover.TsFileRecoverPerformer.recover(TsFileRecoverPerformer.java:143)
at
org.apache.iotdb.db.engine.storagegroup.StorageGroupProcessor.recoverSeqFiles(StorageGroupProcessor.java:294)
at
org.apache.iotdb.db.engine.storagegroup.StorageGroupProcessor.recover(StorageGroupProcessor.java:223)
at
org.apache.iotdb.db.engine.storagegroup.StorageGroupProcessor.(StorageGroupProcessor.java:210)
at
org.apache.iotdb.db.engine.StorageEngine.lambda$new$0(StorageEngine.java:119)
at java.util.concurrent.FutureTask.run(FutureTask.java:266) at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IOTDB-357) NullPointerException in ActiveTimeSeriesCounter
Jialin Qiao created IOTDB-357:
-
Summary: NullPointerException in ActiveTimeSeriesCounter
Key: IOTDB-357
URL: https://issues.apache.org/jira/browse/IOTDB-357
Project: Apache IoTDB
Issue Type: Bug
Reporter: Jialin Qiao
Start a empty IoTDB, execute 3 sql:
{code:java}
SET STORAGE GROUP TO root.turbine;
CREATE TIMESERIES root.turbine.d2.s0 WITH DATATYPE=DOUBLE, ENCODING=GORILLA;
insert into root.turbine.d2(timestamp,s0) values(2,25.3);{code}
Kill the server and restart, then you will see:
{code:java}
11:37:45.157 [pool-1-IoTDB-Recovery-Thread-Pool-thread-1] ERROR
org.apache.iotdb.db.conf.adapter.ActiveTimeSeriesCounter - Storage group
root.turbine- registers active time series root.turbine.d2.s0
failed11:37:45.157 [pool-1-IoTDB-Recovery-Thread-Pool-thread-1] ERROR
org.apache.iotdb.db.conf.adapter.ActiveTimeSeriesCounter - Storage group
root.turbine- registers active time series root.turbine.d2.s0
failedjava.lang.NullPointerException: null at
org.apache.iotdb.db.conf.adapter.ActiveTimeSeriesCounter.offer(ActiveTimeSeriesCounter.java:65)
at
org.apache.iotdb.db.engine.flush.MemTableFlushTask.syncFlushMemTable(MemTableFlushTask.java:87)
at
org.apache.iotdb.db.writelog.recover.TsFileRecoverPerformer.redoLogs(TsFileRecoverPerformer.java:213)
at
org.apache.iotdb.db.writelog.recover.TsFileRecoverPerformer.recover(TsFileRecoverPerformer.java:143)
at
org.apache.iotdb.db.engine.storagegroup.StorageGroupProcessor.recoverSeqFiles(StorageGroupProcessor.java:294)
at
org.apache.iotdb.db.engine.storagegroup.StorageGroupProcessor.recover(StorageGroupProcessor.java:223)
at
org.apache.iotdb.db.engine.storagegroup.StorageGroupProcessor.(StorageGroupProcessor.java:210)
at
org.apache.iotdb.db.engine.StorageEngine.lambda$new$0(StorageEngine.java:119)
at java.util.concurrent.FutureTask.run(FutureTask.java:266) at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)11:37:45.158
[pool-1-IoTDB-Recovery-Thread-Pool-thread-1] ERROR
org.apache.iotdb.db.conf.adapter.ActiveTimeSeriesCounter - Update root.turbine-
active ratio failedjava.lang.NullPointerException: null at
org.apache.iotdb.db.conf.adapter.ActiveTimeSeriesCounter.updateActiveRatio(ActiveTimeSeriesCounter.java:79)
at
org.apache.iotdb.db.engine.flush.MemTableFlushTask.syncFlushMemTable(MemTableFlushTask.java:91)
at
org.apache.iotdb.db.writelog.recover.TsFileRecoverPerformer.redoLogs(TsFileRecoverPerformer.java:213)
at
org.apache.iotdb.db.writelog.recover.TsFileRecoverPerformer.recover(TsFileRecoverPerformer.java:143)
at
org.apache.iotdb.db.engine.storagegroup.StorageGroupProcessor.recoverSeqFiles(StorageGroupProcessor.java:294)
at
org.apache.iotdb.db.engine.storagegroup.StorageGroupProcessor.recover(StorageGroupProcessor.java:223)
at
org.apache.iotdb.db.engine.storagegroup.StorageGroupProcessor.(StorageGroupProcessor.java:210)
at
org.apache.iotdb.db.engine.StorageEngine.lambda$new$0(StorageEngine.java:119)
at java.util.concurrent.FutureTask.run(FutureTask.java:266) at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (IOTDB-356) NullPointerException in ActiveTimeSeriesCounter
[
https://issues.apache.org/jira/browse/IOTDB-356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jialin Qiao closed IOTDB-356.
-
Resolution: Duplicate
https://issues.apache.org/jira/browse/IOTDB-357
> NullPointerException in ActiveTimeSeriesCounter
> ---
>
> Key: IOTDB-356
> URL: https://issues.apache.org/jira/browse/IOTDB-356
> Project: Apache IoTDB
> Issue Type: Bug
>Reporter: Jialin Qiao
>Priority: Major
>
> Start a empty IoTDB, execute 3 sql:
> {code:java}
> SET STORAGE GROUP TO root.turbine;
> CREATE TIMESERIES root.turbine.d2.s0 WITH DATATYPE=DOUBLE, ENCODING=GORILLA;
> insert into root.turbine.d2(timestamp,s0) values(2,25.3);{code}
> Kill the server and restart, then you will see:
> {code:java}
> 11:37:45.157 [pool-1-IoTDB-Recovery-Thread-Pool-thread-1] ERROR
> org.apache.iotdb.db.conf.adapter.ActiveTimeSeriesCounter - Storage group
> root.turbine- registers active time series root.turbine.d2.s0
> failed11:37:45.157 [pool-1-IoTDB-Recovery-Thread-Pool-thread-1] ERROR
> org.apache.iotdb.db.conf.adapter.ActiveTimeSeriesCounter - Storage group
> root.turbine- registers active time series root.turbine.d2.s0
> failedjava.lang.NullPointerException: null at
> org.apache.iotdb.db.conf.adapter.ActiveTimeSeriesCounter.offer(ActiveTimeSeriesCounter.java:65)
> at
> org.apache.iotdb.db.engine.flush.MemTableFlushTask.syncFlushMemTable(MemTableFlushTask.java:87)
> at
> org.apache.iotdb.db.writelog.recover.TsFileRecoverPerformer.redoLogs(TsFileRecoverPerformer.java:213)
> at
> org.apache.iotdb.db.writelog.recover.TsFileRecoverPerformer.recover(TsFileRecoverPerformer.java:143)
> at
> org.apache.iotdb.db.engine.storagegroup.StorageGroupProcessor.recoverSeqFiles(StorageGroupProcessor.java:294)
> at
> org.apache.iotdb.db.engine.storagegroup.StorageGroupProcessor.recover(StorageGroupProcessor.java:223)
> at
> org.apache.iotdb.db.engine.storagegroup.StorageGroupProcessor.(StorageGroupProcessor.java:210)
> at
> org.apache.iotdb.db.engine.StorageEngine.lambda$new$0(StorageEngine.java:119)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)11:37:45.158
> [pool-1-IoTDB-Recovery-Thread-Pool-thread-1] ERROR
> org.apache.iotdb.db.conf.adapter.ActiveTimeSeriesCounter - Update
> root.turbine- active ratio failedjava.lang.NullPointerException: null at
> org.apache.iotdb.db.conf.adapter.ActiveTimeSeriesCounter.updateActiveRatio(ActiveTimeSeriesCounter.java:79)
> at
> org.apache.iotdb.db.engine.flush.MemTableFlushTask.syncFlushMemTable(MemTableFlushTask.java:91)
> at
> org.apache.iotdb.db.writelog.recover.TsFileRecoverPerformer.redoLogs(TsFileRecoverPerformer.java:213)
> at
> org.apache.iotdb.db.writelog.recover.TsFileRecoverPerformer.recover(TsFileRecoverPerformer.java:143)
> at
> org.apache.iotdb.db.engine.storagegroup.StorageGroupProcessor.recoverSeqFiles(StorageGroupProcessor.java:294)
> at
> org.apache.iotdb.db.engine.storagegroup.StorageGroupProcessor.recover(StorageGroupProcessor.java:223)
> at
> org.apache.iotdb.db.engine.storagegroup.StorageGroupProcessor.(StorageGroupProcessor.java:210)
> at
> org.apache.iotdb.db.engine.StorageEngine.lambda$new$0(StorageEngine.java:119)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {code}
>
>
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (IOTDB-342) Merge BytesUtils with ReadWriteIOUtils
[ https://issues.apache.org/jira/browse/IOTDB-342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jialin Qiao closed IOTDB-342. - Resolution: Not A Problem It's not a problem. BytesUtils is for bytes. ReadWriteIOUtils is for IO stream and ByteBuffer. > Merge BytesUtils with ReadWriteIOUtils > -- > > Key: IOTDB-342 > URL: https://issues.apache.org/jira/browse/IOTDB-342 > Project: Apache IoTDB > Issue Type: Improvement >Reporter: Jialin Qiao >Priority: Minor > > In the TsFile module, there are BytesUtils and ReadWriteIOUtils for > serializing and deserializing objects. It's better to merge them and leave > one. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (IOTDB-325) Refactor Statistics
[ https://issues.apache.org/jira/browse/IOTDB-325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jialin Qiao closed IOTDB-325. - Resolution: Fixed > Refactor Statistics > --- > > Key: IOTDB-325 > URL: https://issues.apache.org/jira/browse/IOTDB-325 > Project: Apache IoTDB > Issue Type: Improvement >Reporter: Jialin Qiao >Priority: Minor > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > There are Statistics and StatisticsForFilter in TsFile module, which is in > chaos. > Also, the ByteBuffer[] in Statistics is useless, as the subclass could > serialize and deserialize the fields independently. There is no need to > construct a ByteBuffer[] in the parent class. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (IOTDB-303) Lost users information when upgrading 0.8.x to 0.9.0
[ https://issues.apache.org/jira/browse/IOTDB-303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jialin Qiao closed IOTDB-303. - Resolution: Fixed > Lost users information when upgrading 0.8.x to 0.9.0 > > > Key: IOTDB-303 > URL: https://issues.apache.org/jira/browse/IOTDB-303 > Project: Apache IoTDB > Issue Type: Bug >Reporter: Jialin Qiao >Priority: Minor > Labels: pull-request-available > Time Spent: 40m > Remaining Estimate: 0h > > If creating other users in IoTDB, the upgrade from 0.8.x to 0.9.0 will lost > users except "root". > > In other words, the data/system/user/*.profile is not compatible between > 0.8.x and 0.9.0. Currently, we remove all *.profile and create a new root > user with password root. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (IOTDB-311) Generate anything in test to the target directory.
[ https://issues.apache.org/jira/browse/IOTDB-311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jialin Qiao closed IOTDB-311. - Resolution: Fixed > Generate anything in test to the target directory. > -- > > Key: IOTDB-311 > URL: https://issues.apache.org/jira/browse/IOTDB-311 > Project: Apache IoTDB > Issue Type: Improvement >Reporter: Jialin Qiao >Priority: Major > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > We'd better generate anything in UT/IT to the target directory to avoid > including these files in source release. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (IOTDB-324) Inaccurate Statistics when write batch
[
https://issues.apache.org/jira/browse/IOTDB-324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jialin Qiao closed IOTDB-324.
-
Resolution: Fixed
> Inaccurate Statistics when write batch
> --
>
> Key: IOTDB-324
> URL: https://issues.apache.org/jira/browse/IOTDB-324
> Project: Apache IoTDB
> Issue Type: Bug
>Affects Versions: 0.9.0
>Reporter: Jialin Qiao
>Priority: Major
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When writing a batch in ChunkWriterImpl, the statistics are updated without
> considering the batchSize.
> When writing a 100 size array, batch size is 90, the last 10 points is also
> calculated in the Statistics.
> In ChunkWirterImpl:
> ```
> public void write(long[] timestamps, double[] values, int batchSize) {
> this.maxTimestamp = timestamps[batchSize - 1];
> valueCountInOnePage += batchSize;
> if (minTimestamp == Long.MIN_VALUE) {
> minTimestamp = timestamps[0];
> }
> pageWriter.write(timestamps, values, batchSize);
> pageStatistics.updateStats(values); ** this line is not
> correct
> checkPageSizeAndMayOpenANewPage();
> }
> ```
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (IOTDB-334) Move limit parser to Server side
[
https://issues.apache.org/jira/browse/IOTDB-334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jialin Qiao closed IOTDB-334.
-
Resolution: Fixed
> Move limit parser to Server side
>
>
> Key: IOTDB-334
> URL: https://issues.apache.org/jira/browse/IOTDB-334
> Project: Apache IoTDB
> Issue Type: Improvement
>Reporter: Jialin Qiao
>Priority: Major
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> In our query process, SQL will be analyzed by Antlr in the server-side, then
> generated to a logical plan.
> However, query SQL is also parsed in the client (IoTDBQueryResultSet) by the
> following statement to get the value of the limit clause.
> String[] splited = sql.toUpperCase().split("
> s+");
> This causes extra parsing for a query, which will slow down the query speed.
> I recommend moving the limit parsing to the server-side.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IOTDB-339) Optimize QueryPlan
Jialin Qiao created IOTDB-339: - Summary: Optimize QueryPlan Key: IOTDB-339 URL: https://issues.apache.org/jira/browse/IOTDB-339 Project: Apache IoTDB Issue Type: Improvement Reporter: Jialin Qiao For a query such as "select s1, s1 from root.d1", the query process is as follows: (1) Parse the SQL to a QueryPlan, in which the selected paths are . (2) Return the selected paths to the client for result printing, and recording this QueryPlan in the server. (3) When the client fetches the result, the QueryPlan is passed to QueryProcessExecutor. The executor deduplicate the paths and execute the plan. (4) Return the result set. I recommend moving the deduplication to step (1) and put the origin projected paths and deduplicated paths in QueryPlan. Then, the executor could focus on executing, instead of optimization. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IOTDB-478) Redesign the cache in TsFile/Engine
Jialin Qiao created IOTDB-478: - Summary: Redesign the cache in TsFile/Engine Key: IOTDB-478 URL: https://issues.apache.org/jira/browse/IOTDB-478 Project: Apache IoTDB Issue Type: Improvement Components: Core/Engine, Core/TsFile Reporter: Jialin Qiao Currently, the ChunkLoaderImpl has an internal cache, which is not used in the server. This may cause much gc overhead. I suggest removing the cache in ChunkLoaderImpl, leaving ChunkLoader only a tool, and redesign the cache in TsFile and server. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IOTDB-471) NullPoint exception when merging all TsFiles (may caused by TimeRange Partition)
[
https://issues.apache.org/jira/browse/IOTDB-471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17036170#comment-17036170
]
Jialin Qiao commented on IOTDB-471:
---
We do not figure out how it occurs, only add some log. So this issue is not
closed now.
> NullPoint exception when merging all TsFiles (may caused by TimeRange
> Partition)
>
>
> Key: IOTDB-471
> URL: https://issues.apache.org/jira/browse/IOTDB-471
> Project: Apache IoTDB
> Issue Type: Bug
> Components: Core/Engine
>Reporter: Xiangdong Huang
>Priority: Major
> Labels: pull-request-available
> Fix For: 0.10.0-SNAPSHOT
>
> Attachments: image-2020-02-10-20-32-03-335.png
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Hi,
> In an application, there are millions of time series. In this case, when we
> enable dynamic_parameter, each TsFile has only 7MB.
> Therefore, there are too many TsFiles and the following query is quite slow:
> SELECT longitude,latitude,altitude,'11',windDirection2min,...(other 65
> columns) FROM root.national.*.5.* WHERE time = 2020-01-18 20:00:00 group by
> device
> The above query returns 2400 rows and spends 8 seconds... (Total data is
> just 2GB).
> So, I begin to run merge to accelerate the query speed and the following
> exception occurs:
> !image-2020-02-10-20-32-03-335.png|width=799,height=527!
> If we check the codes, the null point exception is caused by:
>
> {code:java}
>
> private boolean updateLatestFlushTimeCallback(TsFileProcessor processor) {
> // update the largest timestamp in the last flushing memtable
> for (Entry entry :
> latestTimeForEachDevice.get(processor.getTimeRangeId())
> .entrySet()) {
> latestFlushedTimeForEachDevice.get(processor.getTimeRangeId())
> .put(entry.getKey(), entry.getValue());
> }
> return true;
> }
>
> {code}
>
> I know it is hard to reproduce, but can someone help to check and analyze the
> codes?
> Or, at least add more logs for helping to analyze such cases in the future.
> [~SilverNarcissus] [~jt2594838]
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IOTDB-462) Failed to execute goal for `download-maven-plugin`.
[
https://issues.apache.org/jira/browse/IOTDB-462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17034983#comment-17034983
]
Jialin Qiao commented on IOTDB-462:
---
Hi, a user also encounters this problem. Reducing maven-download-plugin to
1.3.0 works. So I'd like to fix it in
[https://github.com/apache/incubator-iotdb/pull/794]
> Failed to execute goal for `download-maven-plugin`.
> ---
>
> Key: IOTDB-462
> URL: https://issues.apache.org/jira/browse/IOTDB-462
> Project: Apache IoTDB
> Issue Type: Bug
> Components: Others
>Reporter: sunjincheng
>Priority: Major
> Attachments: iotdb_mvn.gif
>
>
> Can not build the source code in my local, the error message as follows:
> {code:java}
> [ERROR] Failed to execute goal
> com.googlecode.maven-download-plugin:download-maven-plugin:1.4.0:wget
> (get-thrift-executable) on project service-rpc: Execution
> get-thrift-executable of goal
> com.googlecode.maven-download-plugin:download-maven-plugin:1.4.0:wget failed:
> java.lang.ClassNotFoundException:
> com.googlecode.download.maven.plugin.internal.CachedFileEntry -> [Help 1]
> {code}
> Does anyone else have this problem？
> At present, I have reduced the version（1.3.0） to solve this problem. If most
> of people encounter this problem, I suggest reducing the version to 1.3.0. as
> follows:
> {code:java}
>
>
> com.googlecode.maven-download-plugin
> download-maven-plugin
> 1.3.0 From 1.4.0 to 1.3.0
>
> ...
>
>
> {code}
> What do you think?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IOTDB-462) Failed to execute goal for `download-maven-plugin`.
[
https://issues.apache.org/jira/browse/IOTDB-462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17034985#comment-17034985
]
Jialin Qiao commented on IOTDB-462:
---
[https://github.com/apache/incubator-iotdb/pull/794]
> Failed to execute goal for `download-maven-plugin`.
> ---
>
> Key: IOTDB-462
> URL: https://issues.apache.org/jira/browse/IOTDB-462
> Project: Apache IoTDB
> Issue Type: Bug
> Components: Others
>Affects Versions: 0.8.0, 0.9.0, 0.9.1, 0.8.1, 0.8.2
>Reporter: sunjincheng
>Priority: Major
> Attachments: iotdb_mvn.gif
>
>
> Can not build the source code in my local, the error message as follows:
> {code:java}
> [ERROR] Failed to execute goal
> com.googlecode.maven-download-plugin:download-maven-plugin:1.4.0:wget
> (get-thrift-executable) on project service-rpc: Execution
> get-thrift-executable of goal
> com.googlecode.maven-download-plugin:download-maven-plugin:1.4.0:wget failed:
> java.lang.ClassNotFoundException:
> com.googlecode.download.maven.plugin.internal.CachedFileEntry -> [Help 1]
> {code}
> Does anyone else have this problem？
> At present, I have reduced the version（1.3.0） to solve this problem. If most
> of people encounter this problem, I suggest reducing the version to 1.3.0. as
> follows:
> {code:java}
>
>
> com.googlecode.maven-download-plugin
> download-maven-plugin
> 1.3.0 From 1.4.0 to 1.3.0
>
> ...
>
>
> {code}
> What do you think?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (IOTDB-462) Failed to execute goal for `download-maven-plugin`.
[
https://issues.apache.org/jira/browse/IOTDB-462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jialin Qiao closed IOTDB-462.
-
Fix Version/s: 0.10.0-SNAPSHOT
Resolution: Fixed
> Failed to execute goal for `download-maven-plugin`.
> ---
>
> Key: IOTDB-462
> URL: https://issues.apache.org/jira/browse/IOTDB-462
> Project: Apache IoTDB
> Issue Type: Bug
> Components: Others
>Affects Versions: 0.8.0, 0.9.0, 0.9.1, 0.8.1, 0.8.2
>Reporter: sunjincheng
>Priority: Major
> Labels: pull-request-available
> Fix For: 0.10.0-SNAPSHOT
>
> Attachments: iotdb_mvn.gif
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Can not build the source code in my local, the error message as follows:
> {code:java}
> [ERROR] Failed to execute goal
> com.googlecode.maven-download-plugin:download-maven-plugin:1.4.0:wget
> (get-thrift-executable) on project service-rpc: Execution
> get-thrift-executable of goal
> com.googlecode.maven-download-plugin:download-maven-plugin:1.4.0:wget failed:
> java.lang.ClassNotFoundException:
> com.googlecode.download.maven.plugin.internal.CachedFileEntry -> [Help 1]
> {code}
> Does anyone else have this problem？
> At present, I have reduced the version（1.3.0） to solve this problem. If most
> of people encounter this problem, I suggest reducing the version to 1.3.0. as
> follows:
> {code:java}
>
>
> com.googlecode.maven-download-plugin
> download-maven-plugin
> 1.3.0 From 1.4.0 to 1.3.0
>
> ...
>
>
> {code}
> What do you think?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
