[jira] [Commented] (DRILL-4728) Add support for new metadata fetch APIs
[
https://issues.apache.org/jira/browse/DRILL-4728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15352137#comment-15352137
]
ASF GitHub Bot commented on DRILL-4728:
---
Github user parthchandra commented on a diff in the pull request:
https://github.com/apache/drill/pull/527#discussion_r68682152
--- Diff:
exec/java-exec/src/main/java/org/apache/drill/exec/store/SchemaTreeProvider.java
---
@@ -0,0 +1,105 @@
+/**
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.drill.exec.store;
+
+import org.apache.calcite.jdbc.SimpleCalciteSchema;
+import org.apache.calcite.schema.SchemaPlus;
+import org.apache.drill.common.AutoCloseables;
+import org.apache.drill.common.exceptions.DrillRuntimeException;
+import org.apache.drill.exec.ExecConstants;
+import org.apache.drill.exec.server.DrillbitContext;
+import org.apache.drill.exec.store.SchemaConfig.SchemaConfigInfoProvider;
+import org.apache.drill.exec.util.ImpersonationUtil;
+
+import com.google.common.collect.Lists;
+
+import java.io.IOException;
+import java.util.List;
+
+/**
+ * Class which creates new schema trees. It keeps track of newly created
schema trees and closes them safely as
+ * part of {@link #close()}.
+ */
+public class SchemaTreeProvider implements AutoCloseable {
+ private static final org.slf4j.Logger logger =
org.slf4j.LoggerFactory.getLogger(SchemaTreeProvider.class);
+
+ private final DrillbitContext dContext;
+ private final List schemaTreesToClose;
+ private final boolean isImpersonationEnabled;
+
+ public SchemaTreeProvider(final DrillbitContext dContext) {
+this.dContext = dContext;
+schemaTreesToClose = Lists.newArrayList();
+isImpersonationEnabled =
dContext.getConfig().getBoolean(ExecConstants.IMPERSONATION_ENABLED);
+ }
+
+ /**
+ * Return root schema with schema owner as the given user.
+ *
+ * @param userName Name of the user who is accessing the storage sources.
+ * @param provider {@link SchemaConfigInfoProvider} instance
+ * @return Root of the schema tree.
+ */
+ public SchemaPlus getRootSchema(final String userName, final
SchemaConfigInfoProvider provider) {
+final String schemaUser = isImpersonationEnabled ? userName :
ImpersonationUtil.getProcessUserName();
+final SchemaConfig schemaConfig = SchemaConfig.newBuilder(schemaUser,
provider).build();
+return getRootSchema(schemaConfig);
+ }
+
+ /**
+ * Create and return a SchemaTree with given schemaConfig.
+ * @param schemaConfig
+ * @return
+ */
+ public SchemaPlus getRootSchema(SchemaConfig schemaConfig) {
+try {
+ final SchemaPlus rootSchema =
SimpleCalciteSchema.createRootSchema(false);
+ dContext.getSchemaFactory().registerSchemas(schemaConfig,
rootSchema);
+ schemaTreesToClose.add(rootSchema);
+ return rootSchema;
+} catch(IOException e) {
+ // We can't proceed further without a schema, throw a runtime
exception.
+ final String errMsg = String.format("Failed to create schema tree:
%s", e.getMessage());
+ logger.error(errMsg, e);
+ throw new DrillRuntimeException(errMsg, e);
--- End diff --
Probably should change this to be a UserException (as this will get sent
back to the client)
> Add support for new metadata fetch APIs
> ---
>
> Key: DRILL-4728
> URL: https://issues.apache.org/jira/browse/DRILL-4728
> Project: Apache Drill
> Issue Type: Sub-task
> Components: Metadata
>Reporter: Venki Korukanti
>Assignee: Venki Korukanti
> Fix For: 1.8.0
>
>
> Please see the doc attached to the parent JIRA DRILL-4714 for details on APIs.
> Add support for following APIs (including {{protobuf}} messages, server
> handling code and Java client APIs)
> {code}
>
[jira] [Commented] (DRILL-4728) Add support for new metadata fetch APIs
[
https://issues.apache.org/jira/browse/DRILL-4728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15352138#comment-15352138
]
ASF GitHub Bot commented on DRILL-4728:
---
Github user parthchandra commented on the issue:
https://github.com/apache/drill/pull/527
+1. LGTM with one comment.
> Add support for new metadata fetch APIs
> ---
>
> Key: DRILL-4728
> URL: https://issues.apache.org/jira/browse/DRILL-4728
> Project: Apache Drill
> Issue Type: Sub-task
> Components: Metadata
>Reporter: Venki Korukanti
>Assignee: Venki Korukanti
> Fix For: 1.8.0
>
>
> Please see the doc attached to the parent JIRA DRILL-4714 for details on APIs.
> Add support for following APIs (including {{protobuf}} messages, server
> handling code and Java client APIs)
> {code}
>List getCatalogs(Filter catalogNameFilter)
>List getSchemas(
> Filter catalogNameFilter,
> Filter schemaNameFilter
>)
>List getTables(
> Filter catalogNameFilter,
> Filter schemaNameFilter,
> Filter tableNameFilter
>)
>List getColumns(
> Filter catalogNameFilter,
> Filter schemaNameFilter,
> Filter tableNameFilter,
> Filter columnNameFilter
>)
> {code}
> Note: native client changes are not going to be included in this patch. Will
> file a separate JIRA.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DRILL-4530) Improve metadata cache performance for queries with single partition
[
https://issues.apache.org/jira/browse/DRILL-4530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15352088#comment-15352088
]
ASF GitHub Bot commented on DRILL-4530:
---
Github user amansinha100 commented on a diff in the pull request:
https://github.com/apache/drill/pull/519#discussion_r68678168
--- Diff:
exec/java-exec/src/main/java/org/apache/drill/exec/store/dfs/FileSelection.java
---
@@ -47,16 +47,25 @@
private List statuses;
public List files;
+ /**
+ * root path for the selections
+ */
public final String selectionRoot;
+ /**
+ * root path for the metadata cache file (if any)
+ */
+ public final String cacheFileRoot;
--- End diff --
That was my initial approach (updating the selectionRoot without keeping a
separate cacheFileRoot). However, I ran into a few issues. The main one
that I recall is that the dir0, dir1 etc columns are associated with the
selectionRoot, so suppose I run the following query:
SELECT dir0, dir1 FROM dfs.tmp.t2 WHERE dir0=2015 AND dir1='Q1'
and if the selectionRoot gets modified to point to '2015/Q1' then we have
lost the context of the original dir0, dir1 because everything will become
relative to the new selectionRoot.This produces wrong results. The same
problem occurred with a SELECT * query where the directory columns where not
showing up correctly.
> Improve metadata cache performance for queries with single partition
> -
>
> Key: DRILL-4530
> URL: https://issues.apache.org/jira/browse/DRILL-4530
> Project: Apache Drill
> Issue Type: Improvement
> Components: Query Planning & Optimization
>Affects Versions: 1.6.0
>Reporter: Aman Sinha
>Assignee: Aman Sinha
> Fix For: Future
>
>
> Consider two types of queries which are run with Parquet metadata caching:
> {noformat}
> query 1:
> SELECT col FROM `A/B/C`;
> query 2:
> SELECT col FROM `A` WHERE dir0 = 'B' AND dir1 = 'C';
> {noformat}
> For a certain dataset, the query1 elapsed time is 1 sec whereas query2
> elapsed time is 9 sec even though both are accessing the same amount of data.
> The user expectation is that they should perform roughly the same. The main
> difference comes from reading the bigger metadata cache file at the root
> level 'A' for query2 and then applying the partitioning filter. query1 reads
> a much smaller metadata cache file at the subdirectory level.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DRILL-4707) Conflicting columns names under case-insensitive policy lead to either memory leak or incorrect result
[
https://issues.apache.org/jira/browse/DRILL-4707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15352084#comment-15352084
]
ASF GitHub Bot commented on DRILL-4707:
---
Github user jinfengni commented on the issue:
https://github.com/apache/drill/pull/515
I cherry-picked CALCITE-528 from Calcite master branch, and put it into
Drill forked version.
@amansinha100 , could you please review this PR? thanks!
> Conflicting columns names under case-insensitive policy lead to either memory
> leak or incorrect result
> --
>
> Key: DRILL-4707
> URL: https://issues.apache.org/jira/browse/DRILL-4707
> Project: Apache Drill
> Issue Type: Bug
>Reporter: Jinfeng Ni
>Assignee: Jinfeng Ni
>Priority: Critical
>
> On latest master branch:
> {code}
> select version, commit_id, commit_message from sys.version;
> +-+---+-+
> | version | commit_id |
> commit_message |
> +-+---+-+
> | 1.7.0-SNAPSHOT | 3186217e5abe3c6c2c7e504cdb695567ff577e4c | DRILL-4607:
> Add a split function that allows to separate string by a delimiter |
> +-+---+-+
> {code}
> If a query has two conflicting column names under case-insensitive policy,
> Drill will either hit memory leak, or incorrect issue.
> Q1.
> {code}
> select r_regionkey as XYZ, r_name as xyz FROM cp.`tpch/region.parquet`;
> Error: SYSTEM ERROR: IllegalStateException: Memory was leaked by query.
> Memory leaked: (131072)
> Allocator(op:0:0:1:Project) 100/131072/2490368/100
> (res/actual/peak/limit)
> Fragment 0:0
> {code}
> Q2: return only one column in the result.
> {code}
> select n_nationkey as XYZ, n_regionkey as xyz FROM cp.`tpch/nation.parquet`;
> +--+
> | XYZ |
> +--+
> | 0|
> | 1|
> | 1|
> | 1|
> | 4|
> | 0|
> | 3|
> {code}
> The cause of the problem seems to be that the Project thinks the two incoming
> columns as identical (since Drill adopts case-insensitive for column names in
> execution).
> The planner should make sure that the conflicting columns are resolved, since
> execution is name-based.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DRILL-4530) Improve metadata cache performance for queries with single partition
[
https://issues.apache.org/jira/browse/DRILL-4530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15352020#comment-15352020
]
ASF GitHub Bot commented on DRILL-4530:
---
Github user amansinha100 commented on a diff in the pull request:
https://github.com/apache/drill/pull/519#discussion_r68673292
--- Diff:
exec/java-exec/src/main/java/org/apache/drill/exec/planner/logical/partition/PruneScanRule.java
---
@@ -269,13 +283,54 @@ protected void doOnMatch(RelOptRuleCall call, Filter
filterRel, Project projectR
int recordCount = 0;
int qualifiedCount = 0;
-// Inner loop: within each batch iterate over the
PartitionLocations
-for(PartitionLocation part: partitions){
- if(!output.getAccessor().isNull(recordCount) &&
output.getAccessor().get(recordCount) == 1){
-newPartitions.add(part);
-qualifiedCount++;
+if (checkForSingle &&
+partitions.get(0).isCompositePartition() /* apply single
partition check only for composite partitions */) {
+ // Inner loop: within each batch iterate over the
PartitionLocations
+ for (PartitionLocation part : partitions) {
+assert part.isCompositePartition();
+if(!output.getAccessor().isNull(recordCount) &&
output.getAccessor().get(recordCount) == 1) {
+ newPartitions.add(part);
+ if (isSinglePartition) { // only need to do this if we are
already single partition
+// compose the array of partition values for the
directories that are referenced by filter:
+// e.g suppose the dir hierarchy is year/quarter/month and
the query is:
+// SELECT * FROM T WHERE dir0=2015 AND dir1 = 'Q1',
+// then for 2015/Q1/Feb, this will have ['2015', 'Q1',
null]
--- End diff --
Good point. The path [2015, null, Jan] should *not* qualify for the
single partition optimization because in the general case there could be
multiple 'Jan' subdirectories under the dir1 directory. We would still use the
metadata cache but at the level of the dir0, so ideally one should get
cacheFileRoot=/tmp/t2/2015. I have a fix for this and will update the PR.
> Improve metadata cache performance for queries with single partition
> -
>
> Key: DRILL-4530
> URL: https://issues.apache.org/jira/browse/DRILL-4530
> Project: Apache Drill
> Issue Type: Improvement
> Components: Query Planning & Optimization
>Affects Versions: 1.6.0
>Reporter: Aman Sinha
>Assignee: Aman Sinha
> Fix For: Future
>
>
> Consider two types of queries which are run with Parquet metadata caching:
> {noformat}
> query 1:
> SELECT col FROM `A/B/C`;
> query 2:
> SELECT col FROM `A` WHERE dir0 = 'B' AND dir1 = 'C';
> {noformat}
> For a certain dataset, the query1 elapsed time is 1 sec whereas query2
> elapsed time is 9 sec even though both are accessing the same amount of data.
> The user expectation is that they should perform roughly the same. The main
> difference comes from reading the bigger metadata cache file at the root
> level 'A' for query2 and then applying the partitioning filter. query1 reads
> a much smaller metadata cache file at the subdirectory level.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (DRILL-4715) Java compilation error for a query with large number of expressions
[
https://issues.apache.org/jira/browse/DRILL-4715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinfeng Ni reassigned DRILL-4715:
-
Assignee: Jinfeng Ni
> Java compilation error for a query with large number of expressions
> ---
>
> Key: DRILL-4715
> URL: https://issues.apache.org/jira/browse/DRILL-4715
> Project: Apache Drill
> Issue Type: Bug
> Components: Execution - Codegen
>Reporter: Jinfeng Ni
>Assignee: Jinfeng Ni
> Fix For: 1.8.0
>
>
> The following query would hit compilation error, when Drill generates and
> compiles the run-time code.
> Q1 :
> {code}
> select expr1, expr2, expr3, , exprN
> from table
> {code}
> In Q1, expr1, expr2, ..., exprN are non-trivial expression (in stead of
> simply column reference), and N is big enough, then the run-time generated
> code may have a method which goes beyond the 64k limit imposed by JVM.
> This seems to be a regression from DRILL-3912 (Common subexpression
> elimination). CSE tries to put as many expressions in one block as possible,
> to detect and eliminate as many CSE as possible. However, this implies we may
> end up with big method with compilation error.
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (DRILL-4715) Java compilation error for a query with large number of expressions
[
https://issues.apache.org/jira/browse/DRILL-4715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinfeng Ni resolved DRILL-4715.
---
Resolution: Fixed
Fix Version/s: 1.8.0
Fixed in commit: 11602456b3e7b334c6cd060e633f5668d32d80e9
> Java compilation error for a query with large number of expressions
> ---
>
> Key: DRILL-4715
> URL: https://issues.apache.org/jira/browse/DRILL-4715
> Project: Apache Drill
> Issue Type: Bug
> Components: Execution - Codegen
>Reporter: Jinfeng Ni
>Assignee: Jinfeng Ni
> Fix For: 1.8.0
>
>
> The following query would hit compilation error, when Drill generates and
> compiles the run-time code.
> Q1 :
> {code}
> select expr1, expr2, expr3, , exprN
> from table
> {code}
> In Q1, expr1, expr2, ..., exprN are non-trivial expression (in stead of
> simply column reference), and N is big enough, then the run-time generated
> code may have a method which goes beyond the 64k limit imposed by JVM.
> This seems to be a regression from DRILL-3912 (Common subexpression
> elimination). CSE tries to put as many expressions in one block as possible,
> to detect and eliminate as many CSE as possible. However, this implies we may
> end up with big method with compilation error.
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DRILL-4696) select four table inner join result.Waiting for a long time after drill report error java.lang.OutOfMemoryError: Java heap space
[ https://issues.apache.org/jira/browse/DRILL-4696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15351403#comment-15351403 ] Arina Ielchiieva commented on DRILL-4696: - Queries issued via jdbc in fact being pushed down completely to MySQL. Using batches to return data might resolve the issue. Solution is described in Jira DRILL-4177. > select four table inner join result.Waiting for a long time after drill > report error java.lang.OutOfMemoryError: Java heap space > > > Key: DRILL-4696 > URL: https://issues.apache.org/jira/browse/DRILL-4696 > Project: Apache Drill > Issue Type: Bug > Components: Functions - Drill >Affects Versions: 1.6.0 > Environment: Test Environment: > SUSE Linux Enterprise Server 11 SP3 (x86_64) cluster > MySQL 5.7.11 Enterprise Server - Advanced Edition > Drill cluster >Reporter: david_hudavy > > Test Environment: > cluster 10-3 > MySQL 5.7.11 Enterprise Server - Advanced Edition > Drill cluster > Test Scope: > select performance of huge table(30M records). > MySQL table: a b c d inner join (Four table each have 30M records) > -- four table inner join: (take time Drill Crash) > 0: jdbc:drill:zk=SC-1:6181,SC-2:6181,PL-3:618> select > . . . . . . . . . . . . . . . . . . . . . . .> d.d_5, > . . . . . . . . . . . . . . . . . . . . . . .> c.c_3, > . . . . . . . . . . . . . . . . . . . . . . .> a.a_4, > . . . . . . . . . . . . . . . . . . . . . . .> a.a_5, > . . . . . . . . . . . . . . . . . . . . . . .> a.a_6, > . . . . . . . . . . . . . . . . . . . . . . .> a.a_7, > . . . . . . . . . . . . . . . . . . . . . . .> a.a_8 , > . . . . . . . . . . . . . . . . . . . . . . .> a.a_9 , > . . . . . . . . . . . . . . . . . . . . . . .> a.a_10, > . . . . . . . . . . . . . . . . . . . . . . .> a.a_11 , > . . . . . . . . . . . . . . . . . . . . . . .> a.a_12, > . . . . . . . . . . . . . . . . . . . . . . .> b.b_4 > . . . . . . . . . . . . . . . . . . . . . . .> from > mysql.user_data.a,mysql.user_data.b,mysql.user_data.c,mysql.user_data.d > . . . . . . . . . . . . . . . . . . . . . . .> where c.c_3=a.a_3 and > a.a_3 =b.b_3 and b.b_3=d.d_3 > . . . . . . . . . . . . . . . . . . . . . . .> and c.c_3='0'; > Drill Crash > 2016-05-13 09:52:35,131 [28cacd19-0f04-cbb1-b418-73a76dcd6ebe:frag:0:0] ERROR > o.a.drill.common.CatastrophicFailure - Catastrophic Failure Occurred, > exiting. Information message: Unable to handle out of memory condition in > FragmentExecutor. > java.lang.OutOfMemoryError: Java heap space > at com.mysql.jdbc.MysqlIO.nextRowFast(MysqlIO.java:2157) > ~[mysql-connector-java-5.1.38-bin.jar:5.1.38] > at com.mysql.jdbc.MysqlIO.nextRow(MysqlIO.java:1964) > ~[mysql-connector-java-5.1.38-bin.jar:5.1.38] > at com.mysql.jdbc.MysqlIO.readSingleRowSet(MysqlIO.java:3316) > ~[mysql-connector-java-5.1.38-bin.jar:5.1.38] > at com.mysql.jdbc.MysqlIO.getResultSet(MysqlIO.java:463) > ~[mysql-connector-java-5.1.38-bin.jar:5.1.38] > at > com.mysql.jdbc.MysqlIO.readResultsForQueryOrUpdate(MysqlIO.java:3040) > ~[mysql-connector-java-5.1.38-bin.jar:5.1.38] > at com.mysql.jdbc.MysqlIO.readAllResults(MysqlIO.java:2288) > ~[mysql-connector-java-5.1.38-bin.jar:5.1.38] > at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2681) > ~[mysql-connector-java-5.1.38-bin.jar:5.1.38] > at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2547) > ~[mysql-connector-java-5.1.38-bin.jar:5.1.38] > at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2505) > ~[mysql-connector-java-5.1.38-bin.jar:5.1.38] > at com.mysql.jdbc.StatementImpl.executeQuery(StatementImpl.java:1370) > ~[mysql-connector-java-5.1.38-bin.jar:5.1.38] > at > org.apache.commons.dbcp.DelegatingStatement.executeQuery(DelegatingStatement.java:208) > ~[commons-dbcp-1.4.jar:1.4] > at > org.apache.commons.dbcp.DelegatingStatement.executeQuery(DelegatingStatement.java:208) > ~[commons-dbcp-1.4.jar:1.4] > at > org.apache.drill.exec.store.jdbc.JdbcRecordReader.setup(JdbcRecordReader.java:177) > ~[drill-jdbc-storage-1.6.0.jar:1.6.0] > at > org.apache.drill.exec.physical.impl.ScanBatch.(ScanBatch.java:108) > ~[drill-java-exec-1.6.0.jar:1.6.0] > at > org.apache.drill.exec.physical.impl.ScanBatch.(ScanBatch.java:136) > ~[drill-java-exec-1.6.0.jar:1.6.0] > at > org.apache.drill.exec.store.jdbc.JdbcBatchCreator.getBatch(JdbcBatchCreator.java:40) > ~[drill-jdbc-storage-1.6.0.jar:1.6.0] > at > org.apache.drill.exec.store.jdbc.JdbcBatchCreator.getBatch(JdbcBatchCreator.java:33) >
[jira] [Commented] (DRILL-4171) When exceeded scripts "select * from mscIdentities limit 1;"throwException in thread "WorkManager.StatusThread" java.lang.OutOfMemoryError: GC overhead limit exceeded
[ https://issues.apache.org/jira/browse/DRILL-4171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15351297#comment-15351297 ] Arina Ielchiieva commented on DRILL-4171: - Problems seems the same as indicated in Jira DRILL-4177. Please take a look at comment in DRILL-4177 about adding configuration properties to enable batch read from MySql. > When exceeded scripts "select * from mscIdentities limit 1;"throwException > in thread "WorkManager.StatusThread" java.lang.OutOfMemoryError: GC overhead > limit exceeded > --- > > Key: DRILL-4171 > URL: https://issues.apache.org/jira/browse/DRILL-4171 > Project: Apache Drill > Issue Type: Bug > Components: Functions - Drill >Affects Versions: 1.3.0 > Environment: drill 1.3 jdk7 x86_64 GNU/Linux >Reporter: david_hudavy > > 0: jdbc:drill:zk=local> select * from mscIdentities limit 1; > Exception in thread "WorkManager.StatusThread" java.lang.OutOfMemoryError: GC > overhead limit exceeded > at > java.util.concurrent.ConcurrentHashMap$Values.iterator(ConcurrentHashMap.java:1449) > at > org.apache.drill.exec.work.WorkManager$StatusThread.run(WorkManager.java:309) > Node ran out of Heap memory, exiting. > java.lang.OutOfMemoryError: GC overhead limit exceeded > at com.mysql.jdbc.MysqlIO.nextRowFast(MysqlIO.java:2166) > at com.mysql.jdbc.MysqlIO.nextRow(MysqlIO.java:1956) > at com.mysql.jdbc.MysqlIO.readSingleRowSet(MysqlIO.java:3308) > at com.mysql.jdbc.MysqlIO.getResultSet(MysqlIO.java:463) > at > com.mysql.jdbc.MysqlIO.readResultsForQueryOrUpdate(MysqlIO.java:3032) > at com.mysql.jdbc.MysqlIO.readAllResults(MysqlIO.java:2280) > at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2673) > at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2546) > at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2504) > at com.mysql.jdbc.StatementImpl.executeQuery(StatementImpl.java:1370) > at > org.apache.commons.dbcp.DelegatingStatement.executeQuery(DelegatingStatement.java:208) > at > org.apache.commons.dbcp.DelegatingStatement.executeQuery(DelegatingStatement.java:208) > at > org.apache.drill.exec.store.jdbc.JdbcRecordReader.setup(JdbcRecordReader.java:177) > at > org.apache.drill.exec.physical.impl.ScanBatch.(ScanBatch.java:101) > at > org.apache.drill.exec.physical.impl.ScanBatch.(ScanBatch.java:128) > at > org.apache.drill.exec.store.jdbc.JdbcBatchCreator.getBatch(JdbcBatchCreator.java:40) > at > org.apache.drill.exec.store.jdbc.JdbcBatchCreator.getBatch(JdbcBatchCreator.java:33) > at > org.apache.drill.exec.physical.impl.ImplCreator.getRecordBatch(ImplCreator.java:151) > at > org.apache.drill.exec.physical.impl.ImplCreator.getChildren(ImplCreator.java:174) > at > org.apache.drill.exec.physical.impl.ImplCreator.getRecordBatch(ImplCreator.java:131) > at > org.apache.drill.exec.physical.impl.ImplCreator.getChildren(ImplCreator.java:174) > at > org.apache.drill.exec.physical.impl.ImplCreator.getRecordBatch(ImplCreator.java:131) > at > org.apache.drill.exec.physical.impl.ImplCreator.getChildren(ImplCreator.java:174) > at > org.apache.drill.exec.physical.impl.ImplCreator.getRecordBatch(ImplCreator.java:131) > at > org.apache.drill.exec.physical.impl.ImplCreator.getChildren(ImplCreator.java:174) > at > org.apache.drill.exec.physical.impl.ImplCreator.getRecordBatch(ImplCreator.java:131) > at > org.apache.drill.exec.physical.impl.ImplCreator.getChildren(ImplCreator.java:174) > at > org.apache.drill.exec.physical.impl.ImplCreator.getRootExec(ImplCreator.java:105) > at > org.apache.drill.exec.physical.impl.ImplCreator.getExec(ImplCreator.java:79) > at > org.apache.drill.exec.work.fragment.FragmentExecutor.run(FragmentExecutor.java:230) > at > org.apache.drill.common.SelfCleaningRunnable.run(SelfCleaningRunnable.java:38) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DRILL-4177) select * from table;Node ran out of Heap memory, exiting.java.lang.OutOfMemoryError: GC overhead limit exceeded
[
https://issues.apache.org/jira/browse/DRILL-4177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15351280#comment-15351280
]
Arina Ielchiieva commented on DRILL-4177:
-
Adding configuration properties ?useCursorFetch=true=1 [1]
helps to solve OOM
Here is some guidelines:
1. Before setting up storage plugin for MySql user needs to add
mysql-connector-java-XXX-bin.jar to /jars/3rdparty/. Please mind cursor fetch configuration works from
5.0.0 version [2].
2. MySql version should be > 5.0.2.
3. Add properties to storage plugin configuration:
{
"type": "jdbc",
"driver": "com.mysql.jdbc.Driver",
"url": "jdbc:mysql://host:port?useCursorFetch=true=1",
"username": "XXX",
"password": "XXX",
"enabled": true
}
Fetch size can be adjusted.
[1]
https://dev.mysql.com/doc/connector-j/5.1/en/connector-j-reference-configuration-properties.html
[2] https://dev.mysql.com/downloads/connector/j/
> select * from table;Node ran out of Heap memory,
> exiting.java.lang.OutOfMemoryError: GC overhead limit exceeded
> ---
>
> Key: DRILL-4177
> URL: https://issues.apache.org/jira/browse/DRILL-4177
> Project: Apache Drill
> Issue Type: Bug
> Components: Functions - Drill
>Affects Versions: 1.3.0
> Environment: drill1.3 jdk7
>Reporter: david_hudavy
> Labels: patch
> Original Estimate: 12h
> Remaining Estimate: 12h
>
> 0: jdbc:drill:zk=local> select * from table;
> Node ran out of Heap memory, exiting.
> java.lang.OutOfMemoryError: GC overhead limit exceeded
> at com.mysql.jdbc.MysqlIO.nextRowFast(MysqlIO.java:2149)
> at com.mysql.jdbc.MysqlIO.nextRow(MysqlIO.java:1956)
> at com.mysql.jdbc.MysqlIO.readSingleRowSet(MysqlIO.java:3308)
> at com.mysql.jdbc.MysqlIO.getResultSet(MysqlIO.java:463)
> at
> com.mysql.jdbc.MysqlIO.readResultsForQueryOrUpdate(MysqlIO.java:3032)
> at com.mysql.jdbc.MysqlIO.readAllResults(MysqlIO.java:2280)
> at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2673)
> at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2546)
> at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2504)
> at com.mysql.jdbc.StatementImpl.executeQuery(StatementImpl.java:1370)
> at
> org.apache.commons.dbcp.DelegatingStatement.executeQuery(DelegatingStatement.java:208)
> at
> org.apache.commons.dbcp.DelegatingStatement.executeQuery(DelegatingStatement.java:208)
> at
> org.apache.drill.exec.store.jdbc.JdbcRecordReader.setup(JdbcRecordReader.java:177)
> at
> org.apache.drill.exec.physical.impl.ScanBatch.(ScanBatch.java:101)
> at
> org.apache.drill.exec.physical.impl.ScanBatch.(ScanBatch.java:128)
> at
> org.apache.drill.exec.store.jdbc.JdbcBatchCreator.getBatch(JdbcBatchCreator.java:40)
> at
> org.apache.drill.exec.store.jdbc.JdbcBatchCreator.getBatch(JdbcBatchCreator.java:33)
> at
> org.apache.drill.exec.physical.impl.ImplCreator.getRecordBatch(ImplCreator.java:151)
> at
> org.apache.drill.exec.physical.impl.ImplCreator.getChildren(ImplCreator.java:174)
> at
> org.apache.drill.exec.physical.impl.ImplCreator.getRecordBatch(ImplCreator.java:131)
> at
> org.apache.drill.exec.physical.impl.ImplCreator.getChildren(ImplCreator.java:174)
> at
> org.apache.drill.exec.physical.impl.ImplCreator.getRootExec(ImplCreator.java:105)
> at
> org.apache.drill.exec.physical.impl.ImplCreator.getExec(ImplCreator.java:79)
> at
> org.apache.drill.exec.work.fragment.FragmentExecutor.run(FragmentExecutor.java:230)
> at
> org.apache.drill.common.SelfCleaningRunnable.run(SelfCleaningRunnable.java:38)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DRILL-3474) Add implicit file columns support
[ https://issues.apache.org/jira/browse/DRILL-3474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15350706#comment-15350706 ] ASF GitHub Bot commented on DRILL-3474: --- Github user arina-ielchiieva commented on the issue: https://github.com/apache/drill/pull/491 Changes merged into master with commit id 1ddd0ce7186afd164052d6aa8f63a75fd01148f4 > Add implicit file columns support > - > > Key: DRILL-3474 > URL: https://issues.apache.org/jira/browse/DRILL-3474 > Project: Apache Drill > Issue Type: New Feature > Components: Metadata >Affects Versions: 1.1.0 >Reporter: Jim Scott >Assignee: Arina Ielchiieva > Labels: doc-impacting > Fix For: 1.7.0 > > > I could not find another ticket which talks about this ... > The file name should be a column which can be selected or filtered when > querying a directory just like dir0, dir1 are available. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DRILL-3474) Add implicit file columns support
[ https://issues.apache.org/jira/browse/DRILL-3474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15350707#comment-15350707 ] ASF GitHub Bot commented on DRILL-3474: --- Github user arina-ielchiieva closed the pull request at: https://github.com/apache/drill/pull/491 > Add implicit file columns support > - > > Key: DRILL-3474 > URL: https://issues.apache.org/jira/browse/DRILL-3474 > Project: Apache Drill > Issue Type: New Feature > Components: Metadata >Affects Versions: 1.1.0 >Reporter: Jim Scott >Assignee: Arina Ielchiieva > Labels: doc-impacting > Fix For: 1.7.0 > > > I could not find another ticket which talks about this ... > The file name should be a column which can be selected or filtered when > querying a directory just like dir0, dir1 are available. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-3726) Drill is not properly interpreting CRLF (0d0a). CR gets read as content.
[ https://issues.apache.org/jira/browse/DRILL-3726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arina Ielchiieva updated DRILL-3726: Fix Version/s: (was: 1.7.0) 1.8.0 > Drill is not properly interpreting CRLF (0d0a). CR gets read as content. > > > Key: DRILL-3726 > URL: https://issues.apache.org/jira/browse/DRILL-3726 > Project: Apache Drill > Issue Type: Bug > Components: Storage - Text & CSV >Affects Versions: 1.1.0 > Environment: Linux RHEL 6.6, OSX 10.9 >Reporter: Edmon Begoli >Assignee: Arina Ielchiieva > Fix For: 1.8.0 > > Original Estimate: 120h > Remaining Estimate: 120h > > When we query the last attribute of a text file, we get missing characters. > Looking at the row through Drill, a \r is included at the end of the last > attribute. > Looking in a text editor, it's not embedded into that attribute. > I'm thinking that Drill is not interpreting CRLF (0d0a) as a new line, only > the LF, resulting in the CR becoming part of the last attribute. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (DRILL-3726) Drill is not properly interpreting CRLF (0d0a). CR gets read as content.
[ https://issues.apache.org/jira/browse/DRILL-3726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arina Ielchiieva reopened DRILL-3726: - Assignee: Arina Ielchiieva > Drill is not properly interpreting CRLF (0d0a). CR gets read as content. > > > Key: DRILL-3726 > URL: https://issues.apache.org/jira/browse/DRILL-3726 > Project: Apache Drill > Issue Type: Bug > Components: Storage - Text & CSV >Affects Versions: 1.1.0 > Environment: Linux RHEL 6.6, OSX 10.9 >Reporter: Edmon Begoli >Assignee: Arina Ielchiieva > Fix For: 1.8.0 > > Original Estimate: 120h > Remaining Estimate: 120h > > When we query the last attribute of a text file, we get missing characters. > Looking at the row through Drill, a \r is included at the end of the last > attribute. > Looking in a text editor, it's not embedded into that attribute. > I'm thinking that Drill is not interpreting CRLF (0d0a) as a new line, only > the LF, resulting in the CR becoming part of the last attribute. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DRILL-3726) Drill is not properly interpreting CRLF (0d0a). CR gets read as content.
[ https://issues.apache.org/jira/browse/DRILL-3726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15350700#comment-15350700 ] Arina Ielchiieva commented on DRILL-3726: - Reopening for 1.8 as this relates to DRILL-4746 > Drill is not properly interpreting CRLF (0d0a). CR gets read as content. > > > Key: DRILL-3726 > URL: https://issues.apache.org/jira/browse/DRILL-3726 > Project: Apache Drill > Issue Type: Bug > Components: Storage - Text & CSV >Affects Versions: 1.1.0 > Environment: Linux RHEL 6.6, OSX 10.9 >Reporter: Edmon Begoli >Assignee: Arina Ielchiieva > Fix For: 1.8.0 > > Original Estimate: 120h > Remaining Estimate: 120h > > When we query the last attribute of a text file, we get missing characters. > Looking at the row through Drill, a \r is included at the end of the last > attribute. > Looking in a text editor, it's not embedded into that attribute. > I'm thinking that Drill is not interpreting CRLF (0d0a) as a new line, only > the LF, resulting in the CR becoming part of the last attribute. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (DRILL-3559) Make filename available to sql statments just like dirN
[ https://issues.apache.org/jira/browse/DRILL-3559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arina Ielchiieva resolved DRILL-3559. - Resolution: Fixed > Make filename available to sql statments just like dirN > --- > > Key: DRILL-3559 > URL: https://issues.apache.org/jira/browse/DRILL-3559 > Project: Apache Drill > Issue Type: Improvement > Components: SQL Parser >Affects Versions: 1.1.0 >Reporter: Stefán Baxter >Assignee: Arina Ielchiieva >Priority: Minor > Labels: doc-impacting > Fix For: 1.7.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-3559) Make filename available to sql statments just like dirN
[ https://issues.apache.org/jira/browse/DRILL-3559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arina Ielchiieva updated DRILL-3559: Labels: doc-impacting (was: ) Fix Version/s: (was: Future) 1.7.0 > Make filename available to sql statments just like dirN > --- > > Key: DRILL-3559 > URL: https://issues.apache.org/jira/browse/DRILL-3559 > Project: Apache Drill > Issue Type: Improvement > Components: SQL Parser >Affects Versions: 1.1.0 >Reporter: Stefán Baxter >Assignee: Arina Ielchiieva >Priority: Minor > Labels: doc-impacting > Fix For: 1.7.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DRILL-3559) Make filename available to sql statments just like dirN
[ https://issues.apache.org/jira/browse/DRILL-3559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15350690#comment-15350690 ] Arina Ielchiieva commented on DRILL-3559: - Merged with commit id 1ddd0ce7186afd164052d6aa8f63a75fd01148f4. Bug fixed in Jira DRILL-4733 with commit id 19cdcd95808ddb6f9e19bbccb753017993ad78d6. > Make filename available to sql statments just like dirN > --- > > Key: DRILL-3559 > URL: https://issues.apache.org/jira/browse/DRILL-3559 > Project: Apache Drill > Issue Type: Improvement > Components: SQL Parser >Affects Versions: 1.1.0 >Reporter: Stefán Baxter >Assignee: Arina Ielchiieva >Priority: Minor > Fix For: Future > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DRILL-3474) Add implicit file columns support
[ https://issues.apache.org/jira/browse/DRILL-3474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15350688#comment-15350688 ] Arina Ielchiieva commented on DRILL-3474: - Merged with commit id 1ddd0ce7186afd164052d6aa8f63a75fd01148f4. Bug fixed in Jira DRILL-4733 with commit id 19cdcd95808ddb6f9e19bbccb753017993ad78d6. > Add implicit file columns support > - > > Key: DRILL-3474 > URL: https://issues.apache.org/jira/browse/DRILL-3474 > Project: Apache Drill > Issue Type: New Feature > Components: Metadata >Affects Versions: 1.1.0 >Reporter: Jim Scott >Assignee: Arina Ielchiieva > Labels: doc-impacting > Fix For: 1.7.0 > > > I could not find another ticket which talks about this ... > The file name should be a column which can be selected or filtered when > querying a directory just like dir0, dir1 are available. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (DRILL-3474) Add implicit file columns support
[ https://issues.apache.org/jira/browse/DRILL-3474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arina Ielchiieva resolved DRILL-3474. - Resolution: Fixed > Add implicit file columns support > - > > Key: DRILL-3474 > URL: https://issues.apache.org/jira/browse/DRILL-3474 > Project: Apache Drill > Issue Type: New Feature > Components: Metadata >Affects Versions: 1.1.0 >Reporter: Jim Scott >Assignee: Arina Ielchiieva > Labels: doc-impacting > Fix For: 1.7.0 > > > I could not find another ticket which talks about this ... > The file name should be a column which can be selected or filtered when > querying a directory just like dir0, dir1 are available. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-3474) Add implicit file columns support
[ https://issues.apache.org/jira/browse/DRILL-3474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arina Ielchiieva updated DRILL-3474: Labels: doc-impacting (was: ) Fix Version/s: (was: Future) 1.7.0 Issue Type: New Feature (was: Bug) > Add implicit file columns support > - > > Key: DRILL-3474 > URL: https://issues.apache.org/jira/browse/DRILL-3474 > Project: Apache Drill > Issue Type: New Feature > Components: Metadata >Affects Versions: 1.1.0 >Reporter: Jim Scott >Assignee: Arina Ielchiieva > Labels: doc-impacting > Fix For: 1.7.0 > > > I could not find another ticket which talks about this ... > The file name should be a column which can be selected or filtered when > querying a directory just like dir0, dir1 are available. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DRILL-3559) Make filename available to sql statments just like dirN
[ https://issues.apache.org/jira/browse/DRILL-3559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15350683#comment-15350683 ] Arina Ielchiieva commented on DRILL-3559: - Implementation will add support to four implicit file columns: filename, suffix, fqn, dirname. They will be available during querying file or directory if called explicitly. > Make filename available to sql statments just like dirN > --- > > Key: DRILL-3559 > URL: https://issues.apache.org/jira/browse/DRILL-3559 > Project: Apache Drill > Issue Type: Improvement > Components: SQL Parser >Affects Versions: 1.1.0 >Reporter: Stefán Baxter >Assignee: Arina Ielchiieva >Priority: Minor > Fix For: Future > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (DRILL-4755) StringIndexOutOfBoundsException seen with CONVERT_FROM function
Khurram Faraaz created DRILL-4755:
-
Summary: StringIndexOutOfBoundsException seen with CONVERT_FROM
function
Key: DRILL-4755
URL: https://issues.apache.org/jira/browse/DRILL-4755
Project: Apache Drill
Issue Type: Bug
Components: Query Planning & Optimization
Affects Versions: 1.7.0
Reporter: Khurram Faraaz
StringIndexOutOfBoundsException seen with CONVERT_FROM function
Drill git commit ID : 6286c0a4
{noformat}
0: jdbc:drill:schema=dfs.tmp> select
CONVERT_FROM(binary_string(columns[0]),'INTEGER') from `binStrDuplcs.csv`;
Error: SYSTEM ERROR: StringIndexOutOfBoundsException: String index out of
range: -5
[Error Id: 7e8fd49d-c6ac-40ac-849e-cf59145ed5dd on centos-01.qa.lab:31010]
(org.apache.drill.exec.work.foreman.ForemanException) Unexpected exception
during fragment initialization: String index out of range: -5
org.apache.drill.exec.work.foreman.Foreman.run():271
java.util.concurrent.ThreadPoolExecutor.runWorker():1142
java.util.concurrent.ThreadPoolExecutor$Worker.run():617
java.lang.Thread.run():745
Caused By (java.lang.StringIndexOutOfBoundsException) String index out of
range: -5
java.lang.String.substring():1931
org.apache.drill.exec.planner.logical.PreProcessLogicalRel.getConvertFunctionException():244
org.apache.drill.exec.planner.logical.PreProcessLogicalRel.visit():148
org.apache.calcite.rel.logical.LogicalProject.accept():132
org.apache.drill.exec.planner.sql.handlers.DefaultSqlHandler.preprocessNode():634
org.apache.drill.exec.planner.sql.handlers.DefaultSqlHandler.validateAndConvert():196
org.apache.drill.exec.planner.sql.handlers.DefaultSqlHandler.getPlan():164
org.apache.drill.exec.planner.sql.DrillSqlWorker.getPlan():94
org.apache.drill.exec.work.foreman.Foreman.runSQL():978
org.apache.drill.exec.work.foreman.Foreman.run():257
java.util.concurrent.ThreadPoolExecutor.runWorker():1142
java.util.concurrent.ThreadPoolExecutor$Worker.run():617
java.lang.Thread.run():745 (state=,code=0)
{noformat}
Stack trace from drillbit.log
{noformat}
2016-06-27 05:31:02,515 [288f45e9-44ad-bc5e-3247-3e0ec4dc68e0:foreman] INFO
o.a.drill.exec.work.foreman.Foreman - Query text for query id
288f45e9-44ad-bc5e-3247-3e0ec4dc68e0: select
CONVERT_FROM(binary_string(columns[0]),'INTEGER') from `binStrDuplcs.csv`
2016-06-27 05:31:02,558 [288f45e9-44ad-bc5e-3247-3e0ec4dc68e0:foreman] ERROR
o.a.drill.exec.work.foreman.Foreman - SYSTEM ERROR:
StringIndexOutOfBoundsException: String index out of range: -5
[Error Id: 7e8fd49d-c6ac-40ac-849e-cf59145ed5dd on centos-01.qa.lab:31010]
org.apache.drill.common.exceptions.UserException: SYSTEM ERROR:
StringIndexOutOfBoundsException: String index out of range: -5
[Error Id: 7e8fd49d-c6ac-40ac-849e-cf59145ed5dd on centos-01.qa.lab:31010]
at
org.apache.drill.common.exceptions.UserException$Builder.build(UserException.java:543)
~[drill-common-1.7.0-SNAPSHOT.jar:1.7.0-SNAPSHOT]
at
org.apache.drill.exec.work.foreman.Foreman$ForemanResult.close(Foreman.java:791)
[drill-java-exec-1.7.0-SNAPSHOT.jar:1.7.0-SNAPSHOT]
at
org.apache.drill.exec.work.foreman.Foreman.moveToState(Foreman.java:901)
[drill-java-exec-1.7.0-SNAPSHOT.jar:1.7.0-SNAPSHOT]
at org.apache.drill.exec.work.foreman.Foreman.run(Foreman.java:271)
[drill-java-exec-1.7.0-SNAPSHOT.jar:1.7.0-SNAPSHOT]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
[na:1.8.0_91]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
[na:1.8.0_91]
at java.lang.Thread.run(Thread.java:745) [na:1.8.0_91]
Caused by: org.apache.drill.exec.work.foreman.ForemanException: Unexpected
exception during fragment initialization: String index out of range: -5
... 4 common frames omitted
Caused by: java.lang.StringIndexOutOfBoundsException: String index out of
range: -5
at java.lang.String.substring(String.java:1931) ~[na:1.8.0_91]
at
org.apache.drill.exec.planner.logical.PreProcessLogicalRel.getConvertFunctionException(PreProcessLogicalRel.java:244)
~[drill-java-exec-1.7.0-SNAPSHOT.jar:1.7.0-SNAPSHOT]
at
org.apache.drill.exec.planner.logical.PreProcessLogicalRel.visit(PreProcessLogicalRel.java:148)
~[drill-java-exec-1.7.0-SNAPSHOT.jar:1.7.0-SNAPSHOT]
at
org.apache.calcite.rel.logical.LogicalProject.accept(LogicalProject.java:132)
~[calcite-core-1.4.0-drill-r11.jar:1.4.0-drill-r11]
at
org.apache.drill.exec.planner.sql.handlers.DefaultSqlHandler.preprocessNode(DefaultSqlHandler.java:634)
~[drill-java-exec-1.7.0-SNAPSHOT.jar:1.7.0-SNAPSHOT]
at
org.apache.drill.exec.planner.sql.handlers.DefaultSqlHandler.validateAndConvert(DefaultSqlHandler.java:196)
~[drill-java-exec-1.7.0-SNAPSHOT.jar:1.7.0-SNAPSHOT]
at
