[jira] [Commented] (DRILL-2936) TPCH 4 and 18 SF100 hangs when hash agg is turned off
[
https://issues.apache.org/jira/browse/DRILL-2936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14529841#comment-14529841
]
Steven Phillips commented on DRILL-2936:
The reason this particular query hits this problem is because there is a
HashtoRandom exchange followed by a HashToMerge exchange, both distributed on
the same key, with the same number of fragments.
> TPCH 4 and 18 SF100 hangs when hash agg is turned off
> -
>
> Key: DRILL-2936
> URL: https://issues.apache.org/jira/browse/DRILL-2936
> Project: Apache Drill
> Issue Type: Bug
> Components: Execution - Flow
>Reporter: Ramana Inukonda Nagaraj
>Assignee: Steven Phillips
>Priority: Critical
> Fix For: 1.0.0
>
> Attachments: Screen Shot 2015-05-01 at 2.40.36 PM.png
>
>
> sys options:
> {code}
> 0: jdbc:drill:schema=dfs.drillTestDirTpch100P> alter system set
> `planner.memory.max_query_memory_per_node` = 29205777612;
> 0: jdbc:drill:schema=dfs.drillTestDirTpch100P> alter system set
> `planner.enable_hashjoin`=false;
> 0: jdbc:drill:schema=dfs.drillTestDirTpch100P> alter system set
> `planner.enable_hashagg`=false;
> {code}
> On executing TPCH 04 query hangs. From the profiles page does not look like
> any fragments are making progress, the last progress time stamps were
> sometime back.
> Attached is the logical plan.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DRILL-2936) TPCH 4 and 18 SF100 hangs when hash agg is turned off
[
https://issues.apache.org/jira/browse/DRILL-2936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14529839#comment-14529839
]
Steven Phillips commented on DRILL-2936:
It turns out this is caused by a sort-of deadlock situation condition that can
arise with hash-to-merge exchange. The hash-to-merge exchange consists of a
partition sender and a merging receiver. The partition sender has outgoing
buckets it sends to the different downstream minor fragments. And each merging
receiver has an incoming buffer for each of the sending minor fragments.
The merging receiver cannot proceed without data from each of the sending
fragments. If data from any one of the sending fragments is unavailable, it
will block until it receives some data from that fragment, or a message
indicating there is no more data from that fragment.
If there is some skew in the data, it's possible that a partition sender may
not send any data to a particular receiver. That receiver will end up blocking
because it is waiting to receive that data. Since it is blocked, it is unable
to consume the data that it does receive from other senders. After a few
batches, the sender also blocks due to backpressure, because the receiver is
unable to consume.
Once we reach this state, the query hangs indefinitely.
> TPCH 4 and 18 SF100 hangs when hash agg is turned off
> -
>
> Key: DRILL-2936
> URL: https://issues.apache.org/jira/browse/DRILL-2936
> Project: Apache Drill
> Issue Type: Bug
> Components: Execution - Flow
>Reporter: Ramana Inukonda Nagaraj
>Assignee: Steven Phillips
>Priority: Critical
> Fix For: 1.0.0
>
> Attachments: Screen Shot 2015-05-01 at 2.40.36 PM.png
>
>
> sys options:
> {code}
> 0: jdbc:drill:schema=dfs.drillTestDirTpch100P> alter system set
> `planner.memory.max_query_memory_per_node` = 29205777612;
> 0: jdbc:drill:schema=dfs.drillTestDirTpch100P> alter system set
> `planner.enable_hashjoin`=false;
> 0: jdbc:drill:schema=dfs.drillTestDirTpch100P> alter system set
> `planner.enable_hashagg`=false;
> {code}
> On executing TPCH 04 query hangs. From the profiles page does not look like
> any fragments are making progress, the last progress time stamps were
> sometime back.
> Attached is the logical plan.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (DRILL-1641) kvgen functions fails when the input is an index within a repeated map vector
[
https://issues.apache.org/jira/browse/DRILL-1641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rahul Challapalli closed DRILL-1641.
Verified and added the below testcase
Functional/Passing/json_kvgenflatten/kvgen/kvgen_DRILL-1641.q
> kvgen functions fails when the input is an index within a repeated map vector
> -
>
> Key: DRILL-1641
> URL: https://issues.apache.org/jira/browse/DRILL-1641
> Project: Apache Drill
> Issue Type: Bug
> Components: Execution - Relational Operators, Functions - Drill
>Reporter: Rahul Challapalli
>Assignee: Daniel Barclay (Drill)
> Fix For: 0.7.0
>
> Attachments: DRILL-1641.1.patch, error.log, explain_plan.txt
>
>
> git.commit.id.abbrev=6dca24a
> kvgen function does not work for the below dataset which has an array of maps
> {code}
> {
>"col1" : [
> {"m1":"val1", "m2":"val2"},
> {"m3":"val3", "m4":"val4"}
> ]
> }
> {code}
> Query :
> {code}
> 0: jdbc:drill:schema=dfs> select kvgen(col1[0]) from
> `json_kvgenflatten/temp.json`;
> Query failed: Failure while running fragment. kvgen function only supports
> Simple maps as input [c9bf5998-2198-4b12-a3b8-2a5a7b1e938f]
> Error: exception while executing query: Failure while trying to get next
> result batch. (state=,code=0)
> {code}
> I attached the explain plan and the logs for the failing query. Let me know
> if you need anything else.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (DRILL-2967) Incompatible types error reported in a "not in" query with compatible data types
Victoria Markman created DRILL-2967:
---
Summary: Incompatible types error reported in a "not in" query
with compatible data types
Key: DRILL-2967
URL: https://issues.apache.org/jira/browse/DRILL-2967
Project: Apache Drill
Issue Type: Bug
Components: Query Planning & Optimization
Affects Versions: 0.9.0
Reporter: Victoria Markman
Assignee: Jinfeng Ni
Two tables, parquet files (attached in the bug):
{code}
0: jdbc:drill:schema=dfs> select * from t1;
++++
| a1 | b1 | c1 |
++++
| 1 | a | 2015-01-01 |
| 2 | b | 2015-01-02 |
| 3 | c | 2015-01-03 |
| 4 | null | 2015-01-04 |
| 5 | e | 2015-01-05 |
| 6 | f | 2015-01-06 |
| 7 | g | 2015-01-07 |
| null | h | 2015-01-08 |
| 9 | i | null |
| 10 | j | 2015-01-10 |
++++
10 rows selected (0.119 seconds)
0: jdbc:drill:schema=dfs> select * from t2;
++++
| a2 | b2 | c2 |
++++
| 0 | zzz| 2014-12-31 |
| 1 | a | 2015-01-01 |
| 2 | b | 2015-01-02 |
| 2 | b | 2015-01-02 |
| 2 | b | 2015-01-02 |
| 3 | c | 2015-01-03 |
| 4 | d | 2015-01-04 |
| 5 | e | 2015-01-05 |
| 6 | f | 2015-01-06 |
| 7 | g | 2015-01-07 |
| 7 | g | 2015-01-07 |
| 8 | h | 2015-01-08 |
| 9 | i | 2015-01-09 |
++++
13 rows selected (0.116 seconds)
{code}
Disable hash join and set slice_target = 1:
alter session set `planner.enable_hashjoin` = false;
alter session set `planner.slice_target` = 1;
Correct result:
{code}
0: jdbc:drill:schema=dfs> select * from t1 where b1 not in (select b2 from t2);
++++
| a1 | b1 | c1 |
++++
| 10 | j | 2015-01-10 |
++++
1 row selected (0.625 seconds)
{code}
Swap tables and you get an error:
{code}
0: jdbc:drill:schema=dfs> select * from t2 where b2 not in (select b1 from t1);
++++
| a1 | b1 | c1 |
++++
Query failed: SYSTEM ERROR: Join only supports implicit casts between 1.
Numeric data
2. Varchar, Varbinary data Left type: INT, Right type: VARCHAR. Add explicit
casts to avoid this error
Fragment 1:0
[1a83aa50-39aa-452c-91dd-970bf4a8f03d on atsqa4-133.qa.lab:31010]
java.lang.RuntimeException: java.sql.SQLException: Failure while executing
query.
at sqlline.SqlLine$IncrementalRows.hasNext(SqlLine.java:2514)
at sqlline.SqlLine$TableOutputFormat.print(SqlLine.java:2148)
at sqlline.SqlLine.print(SqlLine.java:1809)
at sqlline.SqlLine$Commands.execute(SqlLine.java:3766)
at sqlline.SqlLine$Commands.sql(SqlLine.java:3663)
at sqlline.SqlLine.dispatch(SqlLine.java:889)
at sqlline.SqlLine.begin(SqlLine.java:763)
at sqlline.SqlLine.start(SqlLine.java:498)
at sqlline.SqlLine.main(SqlLine.java:460)
{code}
Explain plan for the query with an error:
{code}
0: jdbc:drill:schema=dfs> explain plan for select * from t2 where b2 not in
(select b1 from t1);
+++
|text|json|
+++
| 00-00Screen
00-01 Project(*=[$0])
00-02UnionExchange
01-01 Project(T27¦¦*=[$0])
01-02SelectionVectorRemover
01-03 Filter(condition=[NOT(CASE(=($2, 0), false, IS NOT NULL($6),
true, IS NULL($4), null, <($3, $2), null, false))])
01-04MergeJoin(condition=[=($4, $5)], joinType=[left])
01-06 SelectionVectorRemover
01-08Sort(sort0=[$4], dir0=[ASC])
01-10 Project(T27¦¦*=[$0], b2=[$1], $f0=[$2], $f1=[$3],
b20=[$4])
01-12HashToRandomExchange(dist0=[[$4]])
02-01 UnorderedMuxExchange
04-01Project(T27¦¦*=[$0], b2=[$1], $f0=[$2],
$f1=[$3], b20=[$4], E_X_P_R_H_A_S_H_F_I_E_L_D=[castInt(hash64AsDouble($4))])
04-02 Project(T27¦¦*=[$0], b2=[$1], $f0=[$2],
$f1=[$3], b20=[$1])
04-03NestedLoopJoin(condition=[true],
joinType=[inner])
04-05 Project(T27¦¦*=[$0], b2=[$1])
04-06Scan(groupscan=[ParquetGroupScan
[entries=[ReadEntry
[jira] [Closed] (DRILL-1653) flatten function over kvgen gives wrong output when kvgen returns an empty map
[
https://issues.apache.org/jira/browse/DRILL-1653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rahul Challapalli closed DRILL-1653.
Verified and added the below testcase
Functional/Passing/json_kvgenflatten/combo/kvgenflatten_DRILL-1653.q
> flatten function over kvgen gives wrong output when kvgen returns an empty map
> --
>
> Key: DRILL-1653
> URL: https://issues.apache.org/jira/browse/DRILL-1653
> Project: Apache Drill
> Issue Type: Bug
> Components: Functions - Drill, Storage - JSON
>Reporter: Rahul Challapalli
> Fix For: 0.7.0
>
>
> git.commit.id.abbrev=60aa446
> I ran the below test against the private branch of Jason which has some
> patches for bugs related to flatten which are not yet merged into the master.
> Dataset used:
> {code}
> {
> "id": 1,
> "m": {"a":1,"b":2}
> }
> {
> "id": 2
> }
> {
> "id": 3,
> "m": {"c":3,"d":4}
> }
> {code}
> kvgen works as expected
> {code}
> select id, kvgen(m) from `json_kvgenflatten/missing-map.json`;
> +++
> | id | EXPR$1 |
> +++
> | 1 | [{"key":"a","value":1},{"key":"b","value":2}] |
> | 2 | [] |
> | 3 | [{"key":"c","value":3},{"key":"d","value":4}] |
> {code}
> Applying a flatten on top of kvgen returns wrong results
> {code}
> select id, flatten(kvgen(m)) from `json_kvgenflatten/missing-map.json`;
> +++
> | id | EXPR$1 |
> +++
> | 1 | {"key":"\u0001","value":3} |
> | 1 | {"key":"\u0001","value":4} |
> | 3 | {} |
> | 3 | {} |
> +++
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (DRILL-1660) JSON : selecting from an array of empty, null maps results in an exception
[
https://issues.apache.org/jira/browse/DRILL-1660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rahul Challapalli closed DRILL-1660.
Verified and added the below testcase
Functional/Passing/json_kvgenflatten/general/general_empty_DRILL-1660.q
> JSON : selecting from an array of empty, null maps results in an exception
> --
>
> Key: DRILL-1660
> URL: https://issues.apache.org/jira/browse/DRILL-1660
> Project: Apache Drill
> Issue Type: Bug
> Components: Storage - JSON
>Reporter: Rahul Challapalli
>Assignee: Parth Chandra
> Fix For: 0.7.0
>
> Attachments: DRILL-1660.1.patch.txt, error.log
>
>
> git.commit.id.abbrev=60aa446
> I ran the below test against the branch from Jason's github fork which has
> some patches for bugs related to flatten which are not yet merged into the
> master.
> Dataset 1 :
> {code}
> {
> "id":1,
> "evnts":[
> {},
> {"key":null}
> ]
> }
> {code}
> Queries :
> {code}
> 0: jdbc:drill:schema=dfs.drillTestDir> select id, evnts from
> `json_kvgenflatten/empty-null-map.json`;
> +++
> | id | evnts|
> +++
> java.lang.IndexOutOfBoundsException: DrillBuf(ridx: 0, widx: 0, cap: 0/0,
> unwrapped: DrillBuf(ridx: 0, widx: 17, cap: 17/17, unwrapped: DrillBuf(ridx:
> 103, widx: 103, cap: 103/103, unwrapped:
> UnsafeDirectLittleEndian(PooledUnsafeDirectByteBuf(ridx: 0, widx: 0, cap:
> 103/103).slice(0, 8)
> at io.netty.buffer.DrillBuf.(DrillBuf.java:94)
> at io.netty.buffer.DrillBuf.slice(DrillBuf.java:293)
> at org.apache.drill.exec.vector.UInt4Vector.load(UInt4Vector.java:179)
> at
> org.apache.drill.exec.vector.complex.RepeatedMapVector.load(RepeatedMapVector.java:417)
> at
> org.apache.drill.exec.record.RecordBatchLoader.load(RecordBatchLoader.java:91)
> at org.apache.drill.jdbc.DrillCursor.next(DrillCursor.java:102)
> at
> net.hydromatic.avatica.AvaticaResultSet.next(AvaticaResultSet.java:187)
> at sqlline.SqlLine$IncrementalRows.hasNext(SqlLine.java:2503)
> at sqlline.SqlLine$TableOutputFormat.print(SqlLine.java:2148)
> at sqlline.SqlLine.print(SqlLine.java:1809)
> at sqlline.SqlLine$Commands.execute(SqlLine.java:3766)
> at sqlline.SqlLine$Commands.sql(SqlLine.java:3663)
> at sqlline.SqlLine.dispatch(SqlLine.java:889)
> at sqlline.SqlLine.begin(SqlLine.java:763)
> at sqlline.SqlLine.start(SqlLine.java:498)
> at sqlline.SqlLine.main(SqlLine.java:460)
> 0: jdbc:drill:schema=dfs.drillTestDir> select id, flatten(evnts) from
> `json_kvgenflatten/empty-null-map.json`;
> +++
> | id | EXPR$1 |
> +++
> | 1 | {} |
> | 1 | {} |
> +++
> 2 rows selected (0.193 seconds)
> {code}
> Dataset 2:
> {code}
> {"id":1,"evnts":[]}
> {code}
> Queries :
> {code}
> 0: jdbc:drill:schema=dfs.drillTestDir> select id, evnts from
> `json_kvgenflatten/temp.json`;
> +++
> | id | evnts|
> +++
> | 1 | null |
> +++
> 1 row selected (0.12 seconds)
> 0: jdbc:drill:schema=dfs.drillTestDir> select id, flatten(evnts) from
> `json_kvgenflatten/temp.json`;
> Query failed: Failure while running fragment.,
> org.apache.drill.exec.vector.NullableIntVector cannot be cast to
> org.apache.drill.exec.vector.RepeatedVector [
> cb7dfdf1-1f48-4fa1-ac73-6ffbbba0e32a on qa-node191.qa.lab:31010 ]
> Error: exception while executing query: Failure while executing query.
> (state=,code=0)
> {code}
> Dataset 3:
> {code}
> {"id":1,"evnts":[{}]}
> {code}
> Queries :
> {code}
> 0: jdbc:drill:schema=dfs.drillTestDir> select id, evnts from
> `json_kvgenflatten/temp1.json`;
> +++
> | id | evnts|
> +++
> java.lang.IndexOutOfBoundsException: DrillBuf(ridx: 0, widx: 0, cap: 0/0,
> unwrapped: DrillBuf(ridx: 0, widx: 17, cap: 17/17, unwrapped: DrillBuf(ridx:
> 103, widx: 103, cap: 103/103, unwrapped:
> UnsafeDirectLittleEndian(PooledUnsafeDirectByteBuf(ridx: 0, widx: 0, cap:
> 103/103).slice(0, 8)
> at io.netty.buffer.DrillBuf.(DrillBuf.java:94)
> at io.netty.buffer.DrillBuf.slice(DrillBuf.java:293)
> at org.apache.drill.exec.vector.UInt4Vector.load(UInt4Vector.java:179)
> at
> org.apache.drill.exec.vector.complex.RepeatedMapVector.load(RepeatedMapVector.java:417)
> at
> org.apache.drill.exec.record.RecordBatchLoader.load(RecordBatchLoader.java:91)
> at org.apache.drill.jdbc.DrillCursor.next(DrillCursor.java:102)
> at
> net.hydromatic.avatica.AvaticaResultSet.next(AvaticaResultSet.java:187)
>
[jira] [Closed] (DRILL-1665) Flatten operator reports incorrect results when the repeated map has around 100 records or more
[
https://issues.apache.org/jira/browse/DRILL-1665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rahul Challapalli closed DRILL-1665.
Verified and added the below testcase
Functional/Passing/json_kvgenflatten/flatten/flatten_DRILL-1665.q
> Flatten operator reports incorrect results when the repeated map has around
> 100 records or more
> ---
>
> Key: DRILL-1665
> URL: https://issues.apache.org/jira/browse/DRILL-1665
> Project: Apache Drill
> Issue Type: Bug
> Components: Functions - Drill, Storage - JSON
>Reporter: Rahul Challapalli
> Fix For: 0.7.0
>
> Attachments: array-length-100.json
>
>
> git.commit.id.abbrev=60aa446
> I ran the below test against the private branch of Jason which has some
> patches for bugs related to flatten which are not yet merged into the master.
> When we run the flatten operator on a record which contains 100 maps in a
> repeated type, the output is only showing 41 records. However everything
> works fine when repeated type contains only 50 records.
> Below is the query that I used
> {code}
> select id, flatten(evnts) from `json_kvgenflatten/array-length-100.json`;
> ...
> ...
> 40 rows selected (0.2 seconds)
> {code}
> I attached the dataset. Let me know if you have any questions.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DRILL-2966) HAVING clause with CASE statement with IN predicate causes assertion
[
https://issues.apache.org/jira/browse/DRILL-2966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14529719#comment-14529719
]
Sean Hsuan-Yi Chu commented on DRILL-2966:
--
A patch is available from Calcite:
https://issues.apache.org/jira/browse/CALCITE-694
Once that gets checked in, we will add a test case on drill side.
> HAVING clause with CASE statement with IN predicate causes assertion
>
>
> Key: DRILL-2966
> URL: https://issues.apache.org/jira/browse/DRILL-2966
> Project: Apache Drill
> Issue Type: Bug
> Components: Query Planning & Optimization
>Affects Versions: 0.9.0
>Reporter: Aman Sinha
>Assignee: Sean Hsuan-Yi Chu
> Fix For: 1.0.0
>
>
> The following query fails in sql-to-rel conversion:
> {code}
> select count(*) from emp
> group by emp.deptno
> having sum(case when emp.empno in (1, 2, 3) then emp.sal else 0 end)
> between 1.0 and 2.0
> {code}
> {code}
> java.lang.AssertionError: Internal error: while converting CASE WHEN
> `EMP`.`EMPNO` IN (1, 2, 3) THEN `EMP`.`SAL` ELSE 0 END
> at
> org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.convertExpression(SqlToRelConverter.java:4058)
> at
> org.apache.calcite.sql2rel.StandardConvertletTable.convertCase(StandardConvertletTable.java:301)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.apache.calcite.sql2rel.ReflectiveConvertletTable$1.convertCall(ReflectiveConvertletTable.java:87)
> at
> org.apache.calcite.sql2rel.SqlNodeToRexConverterImpl.convertCall(SqlNodeToRexConverterImpl.java:60)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:4212)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:3668)
> at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:130)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.convertExpression(SqlToRelConverter.java:4105)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter$AggConverter.visit(SqlToRelConverter.java:4483)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter$AggConverter.visit(SqlToRelConverter.java:4329)
> at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:130)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter$AggConverter.visit(SqlToRelConverter.java:4528)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter$AggConverter.visit(SqlToRelConverter.java:4329)
> at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:130)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.createAggImpl(SqlToRelConverter.java:2573)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertAgg(SqlToRelConverter.java:2510)
> {code}
> This is dependent on CALCITE-694 .
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (DRILL-1671) Incorrect results reported by drill when we have more than 10 flattens (2048 records)
[
https://issues.apache.org/jira/browse/DRILL-1671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rahul Challapalli closed DRILL-1671.
Verified and added the below testcase
Functional/Passing/json_kvgenflatten/flatten/flatten_DRILL-1671.q
> Incorrect results reported by drill when we have more than 10 flattens (2048
> records)
> --
>
> Key: DRILL-1671
> URL: https://issues.apache.org/jira/browse/DRILL-1671
> Project: Apache Drill
> Issue Type: Bug
> Components: Functions - Drill, Storage - JSON
>Reporter: Rahul Challapalli
> Fix For: 0.7.0
>
> Attachments: many-arrays-50.json
>
>
> git.commit.id.abbrev=60aa446
> I ran the below test against the private branch of Jason which has some
> patches for bugs related to flatten which are not yet merged into the master.
> The data is in such a way that each array within the record contains only 2
> records. So with each flatten added to the query the no of rows should get
> doubled
> The below query works as expected
> {code}
> 0: jdbc:drill:schema=dfs.drillTestDir>select count(*) from (select id,
> flatten(evnts1), flatten(evnts2), flatten(evnts3), flatten(evnts4),
> flatten(evnts5), flatten(evnts6), flatten(evnts7), flatten(evnts8),
> flatten(evnts9), flatten(evnts10) from
> `json_kvgenflatten/many-arrays-50.json`) ;
> ++
> | EXPR$0 |
> ++
> | 1024 |
> ++
> {code}
> However the below query reports incorrect results. The correct output is 2048.
> {code}
> 0: jdbc:drill:schema=dfs.drillTestDir> select count(*) from (select id,
> flatten(evnts1), flatten(evnts2), flatten(evnts3), flatten(evnts4),
> flatten(evnts5), flatten(evnts6), flatten(evnts7), flatten(evnts8),
> flatten(evnts9), flatten(evnts10), flatten(evnts11) from
> `json_kvgenflatten/many-arrays-50.json`) ;
> ++
> | EXPR$0 |
> ++
> | 2047 |
> ++
> {code}
> From here on no matter how many flattens we add to the query, the output
> still remains the same. However the duration of the query seems to more and
> more with each new flatten added.
> I attached the data file. Let me know if you have any questions.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DRILL-2528) Drill-JDBC-All Jar uses outdated classes
[
https://issues.apache.org/jira/browse/DRILL-2528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14529674#comment-14529674
]
Patrick Wong commented on DRILL-2528:
-
If there are any other classes that also need to be accurately preserved - let
me know ASAP
The process that makes the jdbc-all JAR is very aggressive in removing things
it doesn't find in main pathways.
> Drill-JDBC-All Jar uses outdated classes
>
>
> Key: DRILL-2528
> URL: https://issues.apache.org/jira/browse/DRILL-2528
> Project: Apache Drill
> Issue Type: Bug
> Components: Tools, Build & Test
>Affects Versions: 0.8.0
> Environment: RHEL 6.4
>Reporter: Kunal Khatua
>Assignee: DrillCommitter
> Fix For: 1.0.0
>
> Attachments: DRILL-2582.1.patch.txt
>
>
> Since the DrillResultSet.getQueryId() method was unavailable when using the
> Drill-JDBC-All jar, I originally thought there were multiple copies of the
> DrillResultSet class within the code base, but I see only one in GitHub.
> However, when decompiling the two JDBC jar files, the drill-jdbc-all...jar
> shows missing elements within the DrillResultSet class.
> The build creation process is using outdated source code (or dependencies),
> as the following is missing in the DrillResultSet class
> import org.apache.drill.exec.proto.helper.QueryIdHelper;
> public String getQueryId() {
> if (this.queryId != null) {
> return QueryIdHelper.getQueryId(this.queryId);
> }
> return null;
> }
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DRILL-2528) Drill-JDBC-All Jar uses outdated classes
[
https://issues.apache.org/jira/browse/DRILL-2528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Wong updated DRILL-2528:
Assignee: DrillCommitter (was: Patrick Wong)
> Drill-JDBC-All Jar uses outdated classes
>
>
> Key: DRILL-2528
> URL: https://issues.apache.org/jira/browse/DRILL-2528
> Project: Apache Drill
> Issue Type: Bug
> Components: Tools, Build & Test
>Affects Versions: 0.8.0
> Environment: RHEL 6.4
>Reporter: Kunal Khatua
>Assignee: DrillCommitter
> Fix For: 1.0.0
>
> Attachments: DRILL-2582.1.patch.txt
>
>
> Since the DrillResultSet.getQueryId() method was unavailable when using the
> Drill-JDBC-All jar, I originally thought there were multiple copies of the
> DrillResultSet class within the code base, but I see only one in GitHub.
> However, when decompiling the two JDBC jar files, the drill-jdbc-all...jar
> shows missing elements within the DrillResultSet class.
> The build creation process is using outdated source code (or dependencies),
> as the following is missing in the DrillResultSet class
> import org.apache.drill.exec.proto.helper.QueryIdHelper;
> public String getQueryId() {
> if (this.queryId != null) {
> return QueryIdHelper.getQueryId(this.queryId);
> }
> return null;
> }
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DRILL-2528) Drill-JDBC-All Jar uses outdated classes
[
https://issues.apache.org/jira/browse/DRILL-2528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Wong updated DRILL-2528:
Attachment: DRILL-2582.1.patch.txt
DRILL-2582.1.patch.txt - make sure DrillResultSet is accurately preserved in
drill-jdbc-all
> Drill-JDBC-All Jar uses outdated classes
>
>
> Key: DRILL-2528
> URL: https://issues.apache.org/jira/browse/DRILL-2528
> Project: Apache Drill
> Issue Type: Bug
> Components: Tools, Build & Test
>Affects Versions: 0.8.0
> Environment: RHEL 6.4
>Reporter: Kunal Khatua
>Assignee: Patrick Wong
> Fix For: 1.0.0
>
> Attachments: DRILL-2582.1.patch.txt
>
>
> Since the DrillResultSet.getQueryId() method was unavailable when using the
> Drill-JDBC-All jar, I originally thought there were multiple copies of the
> DrillResultSet class within the code base, but I see only one in GitHub.
> However, when decompiling the two JDBC jar files, the drill-jdbc-all...jar
> shows missing elements within the DrillResultSet class.
> The build creation process is using outdated source code (or dependencies),
> as the following is missing in the DrillResultSet class
> import org.apache.drill.exec.proto.helper.QueryIdHelper;
> public String getQueryId() {
> if (this.queryId != null) {
> return QueryIdHelper.getQueryId(this.queryId);
> }
> return null;
> }
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (DRILL-2162) Multiple flattens on a list within a list results in violating the incoming batch size limit
[
https://issues.apache.org/jira/browse/DRILL-2162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rahul Challapalli closed DRILL-2162.
[~jaltekruse] The batch size error went away. But now the query is failing
with an outofmemory error. For the data set with 2 records, the query generates
200 records. My data has 10 records and I expect the query to return
10,000,000 (10 mil) returns. Not sure whether this is a genuine outofmemory
error. Below is my config :
Cluster : 2 nodes
DRILL_MAX_DIRECT_MEMORY="32G"
DRILL_MAX_HEAP="4G"
> Multiple flattens on a list within a list results in violating the incoming
> batch size limit
>
>
> Key: DRILL-2162
> URL: https://issues.apache.org/jira/browse/DRILL-2162
> Project: Apache Drill
> Issue Type: Bug
> Components: Execution - Relational Operators
>Reporter: Rahul Challapalli
>Assignee: Jason Altekruse
> Fix For: 0.9.0
>
> Attachments: data.json, drill-2162.patch
>
>
> git.commit.id.abbrev=3e33880
> I attached the data set with 2 records.
> The below query succeeds on top of the attached data set. However when I
> copied over the same data set 5 times, the same query failed
> {code}
> select uid, flatten(d.lst_lst[1]) lst1, flatten(d.lst_lst[0]) lst0,
> flatten(d.lst_lst) lst from `data.json` d;
> Query failed: RemoteRpcException: Failure while running fragment., Incoming
> batch of org.apache.drill.exec.physical.impl.flatten.FlattenRecordBatch has
> size 102375, which is beyond the limit of 65536 [
> ef16dd95-40e2-4b66-ba30-8650ddb99812 on qa-node190.qa.lab:31010 ]
> [ ef16dd95-40e2-4b66-ba30-8650ddb99812 on qa-node190.qa.lab:31010 ]
> {code}
> Error from the logs :
> {code}
> java.lang.IllegalStateException: Incoming batch of
> org.apache.drill.exec.physical.impl.flatten.FlattenRecordBatch has size
> 102375, which is beyond the limit of 65536
> at
> org.apache.drill.exec.physical.impl.validate.IteratorValidatorBatchIterator.next(IteratorValidatorBatchIterator.java:129)
> ~[drill-java-exec-0.8.0-SNAPSHOT-rebuffed.jar:0.8.0-SNAPSHOT]
> at
> org.apache.drill.exec.record.AbstractRecordBatch.next(AbstractRecordBatch.java:99)
> ~[drill-java-exec-0.8.0-SNAPSHOT-rebuffed.jar:0.8.0-SNAPSHOT]
> at
> org.apache.drill.exec.record.AbstractRecordBatch.next(AbstractRecordBatch.java:89)
> ~[drill-java-exec-0.8.0-SNAPSHOT-rebuffed.jar:0.8.0-SNAPSHOT]
> at
> org.apache.drill.exec.record.AbstractSingleRecordBatch.innerNext(AbstractSingleRecordBatch.java:51)
> ~[drill-java-exec-0.8.0-SNAPSHOT-rebuffed.jar:0.8.0-SNAPSHOT]
> at
> org.apache.drill.exec.physical.impl.project.ProjectRecordBatch.innerNext(ProjectRecordBatch.java:134)
> ~[drill-java-exec-0.8.0-SNAPSHOT-rebuffed.jar:0.8.0-SNAPSHOT]
> at
> org.apache.drill.exec.record.AbstractRecordBatch.next(AbstractRecordBatch.java:142)
> ~[drill-java-exec-0.8.0-SNAPSHOT-rebuffed.jar:0.8.0-SNAPSHOT]
> at
> org.apache.drill.exec.physical.impl.validate.IteratorValidatorBatchIterator.next(IteratorValidatorBatchIterator.java:118)
> ~[drill-java-exec-0.8.0-SNAPSHOT-rebuffed.jar:0.8.0-SNAPSHOT]
> at
> org.apache.drill.exec.record.AbstractRecordBatch.next(AbstractRecordBatch.java:99)
> ~[drill-java-exec-0.8.0-SNAPSHOT-rebuffed.jar:0.8.0-SNAPSHOT]
> at
> org.apache.drill.exec.record.AbstractRecordBatch.next(AbstractRecordBatch.java:89)
> ~[drill-java-exec-0.8.0-SNAPSHOT-rebuffed.jar:0.8.0-SNAPSHOT]
> at
> org.apache.drill.exec.record.AbstractSingleRecordBatch.innerNext(AbstractSingleRecordBatch.java:51)
> ~[drill-java-exec-0.8.0-SNAPSHOT-rebuffed.jar:0.8.0-SNAPSHOT]
> at
> org.apache.drill.exec.physical.impl.flatten.FlattenRecordBatch.innerNext(FlattenRecordBatch.java:122)
> ~[drill-java-exec-0.8.0-SNAPSHOT-rebuffed.jar:0.8.0-SNAPSHOT]
> at
> org.apache.drill.exec.record.AbstractRecordBatch.next(AbstractRecordBatch.java:142)
> ~[drill-java-exec-0.8.0-SNAPSHOT-rebuffed.jar:0.8.0-SNAPSHOT]
> at
> org.apache.drill.exec.physical.impl.validate.IteratorValidatorBatchIterator.next(IteratorValidatorBatchIterator.java:118)
> ~[drill-java-exec-0.8.0-SNAPSHOT-rebuffed.jar:0.8.0-SNAPSHOT]
> at
> org.apache.drill.exec.record.AbstractRecordBatch.next(AbstractRecordBatch.java:99)
> ~[drill-java-exec-0.8.0-SNAPSHOT-rebuffed.jar:0.8.0-SNAPSHOT]
> at
> org.apache.drill.exec.record.AbstractRecordBatch.next(AbstractRecordBatch.java:89)
> ~[drill-java-exec-0.8.0-SNAPSHOT-rebuffed.jar:0.8.0-SNAPSHOT]
> at
> org.apache.drill.exec.record.AbstractSingleRecordBatch.innerNext(AbstractSingleRecordBatch.java:51)
> ~[drill-java-exec-0.8.0-SNAPSHOT-rebuffed.jar:0.8.0-SNAPSHOT]
> at
> org.apache.drill.exec.physical.impl.project.Proje
[jira] [Closed] (DRILL-2181) Throw proper error message when flatten is used within an 'order by' or 'group by'
[
https://issues.apache.org/jira/browse/DRILL-2181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rahul Challapalli closed DRILL-2181.
> Throw proper error message when flatten is used within an 'order by' or
> 'group by'
> --
>
> Key: DRILL-2181
> URL: https://issues.apache.org/jira/browse/DRILL-2181
> Project: Apache Drill
> Issue Type: Bug
> Components: Query Planning & Optimization
>Reporter: Rahul Challapalli
>Assignee: Sean Hsuan-Yi Chu
> Fix For: 1.0.0
>
> Attachments: DRILL-2181.1.patch
>
>
> git.commit.id.abbrev=c54bd6a
> Flatten can be used within a group by or order by statement when the output
> of flatten is a scalar. However drill currently does not support using
> flatten with the above operators when its output is not a scalar. In such
> cases we should show a more appropriate error, possibly indicating how to
> correct the query as well
> Currently this is what we get. This is obscure and does not pinpoint the issue
> {code}
> select * from `data1.json` order by flatten(events);
> Query failed: RemoteRpcException: Failure while running fragment.,
> org.apache.drill.exec.vector.NullableIntVector cannot be cast to
> org.apache.drill.exec.vector.RepeatedVector [
> c3d85d23-7ea0-43ea-bbd3-ac18a0aa2de3 on qa-node191.qa.lab:31010 ]
> [ c3d85d23-7ea0-43ea-bbd3-ac18a0aa2de3 on qa-node191.qa.lab:31010 ]
> Error: exception while executing query: Failure while executing query.
> (state=,code=0)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (DRILL-2292) CTAS broken when we have repeated maps
[
https://issues.apache.org/jira/browse/DRILL-2292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rahul Challapalli closed DRILL-2292.
Verified and added the below testcase
Functional/Passing/ctas_flatten/2rows/q_DRILL-2292.q
> CTAS broken when we have repeated maps
> --
>
> Key: DRILL-2292
> URL: https://issues.apache.org/jira/browse/DRILL-2292
> Project: Apache Drill
> Issue Type: Bug
> Components: Storage - Parquet
>Reporter: Rahul Challapalli
>Assignee: Deneche A. Hakim
>Priority: Blocker
> Fix For: 1.0.0
>
> Attachments: DRILL-2292.1.patch.txt, DRILL-2292.2.patch.txt,
> DRILL-2292.3.patch.txt, DRILL-2292.4.patch.txt
>
>
> git.commit.id.abbrev=6676f2d
> Data Set :
> {code}
> {
> "id" : 1,
> "map":{"rm": [
> {"mapid":"m1","mapvalue":{"col1":1,"col2":[0,1,2,3,4,5]},"rptd": [{ "a":
> "foo"},{"b":"boo"}]},
> {"mapid":"m2","mapvalue":{"col1":0,"col2":[]},"rptd": [{ "a":
> "bar"},{"c":1},{"d":4.5}]}
> ]}
> }
> {code}
> The below CTAS statement fails though the underlying query succeeds
> {code}
> create table rep_map as select d.map from `temp.json` d;
> Query failed: Query stopped., index: -4, length: 4 (expected: range(0,
> 16384)) [ d76e3f74-7e2c-406f-a7fd-5efc68227e75 on qa-node190.qa.lab:31010 ]
> {code}
> Error from the logs :
> {code}
> Caused by: java.lang.IndexOutOfBoundsException: index: -4, length: 4
> (expected: range(0, 16384))
> at io.netty.buffer.DrillBuf.checkIndexD(DrillBuf.java:156)
> ~[drill-java-exec-0.8.0-SNAPSHOT-rebuffed.jar:4.0.24.Final]
> at io.netty.buffer.DrillBuf.chk(DrillBuf.java:178)
> ~[drill-java-exec-0.8.0-SNAPSHOT-rebuffed.jar:4.0.24.Final]
> at io.netty.buffer.DrillBuf.getInt(DrillBuf.java:447)
> ~[drill-java-exec-0.8.0-SNAPSHOT-rebuffed.jar:4.0.24.Final]
> at
> org.apache.drill.exec.vector.UInt4Vector$Accessor.get(UInt4Vector.java:309)
> ~[drill-java-exec-0.8.0-SNAPSHOT-rebuffed.jar:0.8.0-SNAPSHOT]
> at
> org.apache.drill.exec.vector.complex.RepeatedMapVector$RepeatedMapAccessor.get(RepeatedMapVector.java:451)
> ~[drill-java-exec-0.8.0-SNAPSHOT-rebuffed.jar:0.8.0-SNAPSHOT]
> at
> org.apache.drill.exec.vector.complex.impl.RepeatedMapReaderImpl.setPosition(RepeatedMapReaderImpl.java:90)
> ~[drill-java-exec-0.8.0-SNAPSHOT-rebuffed.jar:0.8.0-SNAPSHOT]
> at
> org.apache.drill.exec.vector.complex.impl.RepeatedMapReaderImpl.reader(RepeatedMapReaderImpl.java:60)
> ~[drill-java-exec-0.8.0-SNAPSHOT-rebuffed.jar:0.8.0-SNAPSHOT]
> at
> org.apache.drill.exec.store.parquet.ParquetRecordWriter$RepeatedMapParquetConverter.(ParquetRecordWriter.java:269)
> ~[drill-java-exec-0.8.0-SNAPSHOT-rebuffed.jar:0.8.0-SNAPSHOT]
> at
> org.apache.drill.exec.store.parquet.ParquetRecordWriter.getNewRepeatedMapConverter(ParquetRecordWriter.java:259)
> ~[drill-java-exec-0.8.0-SNAPSHOT-rebuffed.jar:0.8.0-SNAPSHOT]
> at
> org.apache.drill.exec.store.EventBasedRecordWriter.getConverter(EventBasedRecordWriter.java:116)
> ~[drill-java-exec-0.8.0-SNAPSHOT-rebuffed.jar:0.8.0-SNAPSHOT]
> at
> org.apache.drill.exec.store.parquet.ParquetRecordWriter$MapParquetConverter.(ParquetRecordWriter.java:240)
> ~[drill-java-exec-0.8.0-SNAPSHOT-rebuffed.jar:0.8.0-SNAPSHOT]
> at
> org.apache.drill.exec.store.parquet.ParquetRecordWriter.getNewMapConverter(ParquetRecordWriter.java:230)
> ~[drill-java-exec-0.8.0-SNAPSHOT-rebuffed.jar:0.8.0-SNAPSHOT]
> at
> org.apache.drill.exec.store.EventBasedRecordWriter.getConverter(EventBasedRecordWriter.java:114)
> ~[drill-java-exec-0.8.0-SNAPSHOT-rebuffed.jar:0.8.0-SNAPSHOT]
> at
> org.apache.drill.exec.store.EventBasedRecordWriter.initFieldWriters(EventBasedRecordWriter.java:73)
> ~[drill-java-exec-0.8.0-SNAPSHOT-rebuffed.jar:0.8.0-SNAPSHOT]
> ... 19 common frames omitted
> 2015-02-24 19:05:56,898 [2b13346a-d929-d659-c074-354c9f5d9d4f:frag:0:0] ERROR
> o.a.d.e.p.i.ScreenCreator$ScreenRoot - Error
> 7c8fa189-8f0a-4763-a266-fd68a11bbb66: Query stopped.
> java.io.IOException: Failed to initialize FieldWriters.
> at
> org.apache.drill.exec.store.EventBasedRecordWriter.initFieldWriters(EventBasedRecordWriter.java:78)
> ~[drill-java-exec-0.8.0-SNAPSHOT-rebuffed.jar:0.8.0-SNAPSHOT]
> at
> org.apache.drill.exec.store.EventBasedRecordWriter.(EventBasedRecordWriter.java:46)
> ~[drill-java-exec-0.8.0-SNAPSHOT-rebuffed.jar:0.8.0-SNAPSHOT]
> at
> org.apache.drill.exec.physical.impl.WriterRecordBatch.setupNewSchema(WriterRecordBatch.java:176)
> ~[drill-java-exec-0.8.0-SNAPSHOT-rebuffed.jar:0.8.0-SNAPSHOT]
> at
> org.apache.drill.exec.physical.impl.WriterRecordBatch.innerNext(WriterRecordBatch.java:113)
> ~[drill-java-exec-0.8.0-SNAPSHOT-rebuffed.jar:0.8.0-SNAPSHOT]
> at
> o
[jira] [Commented] (DRILL-1662) drillbit.sh stop should timeout
[ https://issues.apache.org/jira/browse/DRILL-1662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14529589#comment-14529589 ] Ramana Inukonda Nagaraj commented on DRILL-1662: Verified that export DRILL_STOP_TIMEOUT works fine. [~jnadeau] How much of a time out do we want by default? > drillbit.sh stop should timeout > --- > > Key: DRILL-1662 > URL: https://issues.apache.org/jira/browse/DRILL-1662 > Project: Apache Drill > Issue Type: Improvement > Components: Tools, Build & Test >Reporter: Ramana Inukonda Nagaraj >Assignee: Ramana Inukonda Nagaraj > Fix For: 1.0.0 > > > We need a timeout as part of the drillbit.sh stop > Can we have a configurable parameter with a default of 30 seconds and after > that the timeout should kill the drillbit.sh -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-2304) Case sensitivity - system and session options are case sensitive
[
https://issues.apache.org/jira/browse/DRILL-2304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheesh Katkam updated DRILL-2304:
---
Attachment: DRILL-2304.2.patch.txt
> Case sensitivity - system and session options are case sensitive
>
>
> Key: DRILL-2304
> URL: https://issues.apache.org/jira/browse/DRILL-2304
> Project: Apache Drill
> Issue Type: Bug
> Components: Storage - Information Schema
>Affects Versions: 0.8.0
>Reporter: Ramana Inukonda Nagaraj
>Assignee: Sudheesh Katkam
>Priority: Minor
> Fix For: 1.2.0
>
> Attachments: DRILL-2304.1.patch.txt, DRILL-2304.2.patch.txt
>
>
> TBH I am not sure if this is a bug.
> When trying to set a session option and I specify the name in a different
> case the alter command fails. Considering the way we store session options
> this might be an invalid bug but considering how typical Database hints and
> options work this is a bug.
> {code}
> 0: jdbc:drill:> alter SESSION set `STORE.PARQUET.COMPRESSION`='GZIP';
> Query failed: SetOptionException: Unknown option: STORE.PARQUET.COMPRESSION
> Error: exception while executing query: Failure while executing query.
> (state=,code=0)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DRILL-2304) Case sensitivity - system and session options are case sensitive
[
https://issues.apache.org/jira/browse/DRILL-2304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheesh Katkam updated DRILL-2304:
---
Assignee: Jason Altekruse (was: Sudheesh Katkam)
> Case sensitivity - system and session options are case sensitive
>
>
> Key: DRILL-2304
> URL: https://issues.apache.org/jira/browse/DRILL-2304
> Project: Apache Drill
> Issue Type: Bug
> Components: Storage - Information Schema
>Affects Versions: 0.8.0
>Reporter: Ramana Inukonda Nagaraj
>Assignee: Jason Altekruse
>Priority: Minor
> Fix For: 1.2.0
>
> Attachments: DRILL-2304.1.patch.txt, DRILL-2304.2.patch.txt
>
>
> TBH I am not sure if this is a bug.
> When trying to set a session option and I specify the name in a different
> case the alter command fails. Considering the way we store session options
> this might be an invalid bug but considering how typical Database hints and
> options work this is a bug.
> {code}
> 0: jdbc:drill:> alter SESSION set `STORE.PARQUET.COMPRESSION`='GZIP';
> Query failed: SetOptionException: Unknown option: STORE.PARQUET.COMPRESSION
> Error: exception while executing query: Failure while executing query.
> (state=,code=0)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (DRILL-2966) HAVING clause with CASE statement with IN predicate causes assertion
Aman Sinha created DRILL-2966:
-
Summary: HAVING clause with CASE statement with IN predicate
causes assertion
Key: DRILL-2966
URL: https://issues.apache.org/jira/browse/DRILL-2966
Project: Apache Drill
Issue Type: Bug
Components: Query Planning & Optimization
Affects Versions: 0.9.0
Reporter: Aman Sinha
Assignee: Sean Hsuan-Yi Chu
Fix For: 1.0.0
The following query fails in sql-to-rel conversion:
{code}
select count(*) from emp
group by emp.deptno
having sum(case when emp.empno in (1, 2, 3) then emp.sal else 0 end)
between 1.0 and 2.0
{code}
{code}
java.lang.AssertionError: Internal error: while converting CASE WHEN
`EMP`.`EMPNO` IN (1, 2, 3) THEN `EMP`.`SAL` ELSE 0 END
at
org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.convertExpression(SqlToRelConverter.java:4058)
at
org.apache.calcite.sql2rel.StandardConvertletTable.convertCase(StandardConvertletTable.java:301)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.apache.calcite.sql2rel.ReflectiveConvertletTable$1.convertCall(ReflectiveConvertletTable.java:87)
at
org.apache.calcite.sql2rel.SqlNodeToRexConverterImpl.convertCall(SqlNodeToRexConverterImpl.java:60)
at
org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:4212)
at
org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:3668)
at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:130)
at
org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.convertExpression(SqlToRelConverter.java:4105)
at
org.apache.calcite.sql2rel.SqlToRelConverter$AggConverter.visit(SqlToRelConverter.java:4483)
at
org.apache.calcite.sql2rel.SqlToRelConverter$AggConverter.visit(SqlToRelConverter.java:4329)
at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:130)
at
org.apache.calcite.sql2rel.SqlToRelConverter$AggConverter.visit(SqlToRelConverter.java:4528)
at
org.apache.calcite.sql2rel.SqlToRelConverter$AggConverter.visit(SqlToRelConverter.java:4329)
at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:130)
at
org.apache.calcite.sql2rel.SqlToRelConverter.createAggImpl(SqlToRelConverter.java:2573)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertAgg(SqlToRelConverter.java:2510)
{code}
This is dependent on CALCITE-694 .
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DRILL-2528) Drill-JDBC-All Jar uses outdated classes
[
https://issues.apache.org/jira/browse/DRILL-2528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14529529#comment-14529529
]
Patrick Wong commented on DRILL-2528:
-
I looked at the 0.9.0 release with a decompiler
DrillResultSet.class in jdbc-all has no content at all. Will look into it.
> Drill-JDBC-All Jar uses outdated classes
>
>
> Key: DRILL-2528
> URL: https://issues.apache.org/jira/browse/DRILL-2528
> Project: Apache Drill
> Issue Type: Bug
> Components: Tools, Build & Test
>Affects Versions: 0.8.0
> Environment: RHEL 6.4
>Reporter: Kunal Khatua
>Assignee: Patrick Wong
> Fix For: 1.0.0
>
>
> Since the DrillResultSet.getQueryId() method was unavailable when using the
> Drill-JDBC-All jar, I originally thought there were multiple copies of the
> DrillResultSet class within the code base, but I see only one in GitHub.
> However, when decompiling the two JDBC jar files, the drill-jdbc-all...jar
> shows missing elements within the DrillResultSet class.
> The build creation process is using outdated source code (or dependencies),
> as the following is missing in the DrillResultSet class
> import org.apache.drill.exec.proto.helper.QueryIdHelper;
> public String getQueryId() {
> if (this.queryId != null) {
> return QueryIdHelper.getQueryId(this.queryId);
> }
> return null;
> }
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (DRILL-2965) Unit tests for REST API
Sudheesh Katkam created DRILL-2965: -- Summary: Unit tests for REST API Key: DRILL-2965 URL: https://issues.apache.org/jira/browse/DRILL-2965 Project: Apache Drill Issue Type: Task Components: Client - HTTP Reporter: Sudheesh Katkam Assignee: Sudheesh Katkam Fix For: 1.2.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-2508) Add new column to sys.options table that exposes whether or not the current system value is the default
[ https://issues.apache.org/jira/browse/DRILL-2508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudheesh Katkam updated DRILL-2508: --- Assignee: Jason Altekruse (was: Sudheesh Katkam) > Add new column to sys.options table that exposes whether or not the current > system value is the default > --- > > Key: DRILL-2508 > URL: https://issues.apache.org/jira/browse/DRILL-2508 > Project: Apache Drill > Issue Type: Improvement > Components: Storage - Other >Reporter: Victoria Markman >Assignee: Jason Altekruse > Fix For: 1.0.0 > > Attachments: DRILL-2508.1.patch.txt, DRILL-2508.2.patch.txt > > > Need to be able to see system parameters that I changed. > There is an enhancement already to reset them to default values: drill-1065 > I don't necessarily want to do that, I just want to see only things that I > changed : default value vs. my change. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-2928) C++ Client - io_service needs to be reset if it runs out of work
[ https://issues.apache.org/jira/browse/DRILL-2928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Parth Chandra updated DRILL-2928: - Attachment: DRILL-2928.1.patch.diff Review Board: https://reviews.apache.org/r/33812/ > C++ Client - io_service needs to be reset if it runs out of work > > > Key: DRILL-2928 > URL: https://issues.apache.org/jira/browse/DRILL-2928 > Project: Apache Drill > Issue Type: Bug > Components: Client - C++ >Reporter: Parth Chandra >Assignee: Parth Chandra > Fix For: 1.0.0 > > Attachments: DRILL-2928.1.patch.diff > > > Sumbitting multiple queries in sequence using the async api can result in a > situation where the io_service runs out of work before the next query is > submitted and stops running. Any listener thread started using the io_service > then exits immediately. > A previous patch did not address this fully. Once it runs out of work, the > io_service needs to be reset before it is assigned more work. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DRILL-2951) Tables are not visible when Drillbit is specified in the connection URL
[ https://issues.apache.org/jira/browse/DRILL-2951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14529492#comment-14529492 ] Parth Chandra commented on DRILL-2951: -- Review Board: https://reviews.apache.org/r/33859/ > Tables are not visible when Drillbit is specified in the connection URL > --- > > Key: DRILL-2951 > URL: https://issues.apache.org/jira/browse/DRILL-2951 > Project: Apache Drill > Issue Type: Bug > Components: Client - JDBC >Affects Versions: 0.9.0 > Environment: RHEL 6.4 >Reporter: Kunal Khatua >Assignee: Parth Chandra >Priority: Blocker > Fix For: 1.0.0 > > Attachments: DRILL-2951.1.patch.diff > > > When running a query against a Drill cluster without specifying the drillbit, > the query executes correctly and without issue: > Connection Example: > [TestClient] -Dconn="jdbc:drill:schema=dfs.drill" PipSQueak 01_par100.q > [STAT] Query : > select l_returnflag, l_linestatus, sum(l_quantity) as sum_qty, > sum(l_extendedprice) as sum_base_price, sum(l_extendedprice * (1 - > l_discount)) as sum_disc_price, sum(l_extendedprice * (1 - l_discount) * (1 + > l_tax)) as sum_charge, avg(l_quantity) as avg_qty, avg(l_extendedprice) as > avg_price, avg(l_discount) as avg_disc, count(*) as count_order from > lineitem_par100 where l_shipdate <= date '1998-12-01' - interval '120' day > (3) group by l_returnflag, l_linestatus order by l_returnflag, l_linestatus > [STAT] Rows Fetched : 4 > [STAT] TOTAL TIME : 32142 msec > However, when the Drillbit is specified (even on the same Drillbit where the > query was previously submitted), we get a parse error: > Query failed: PARSE ERROR: From line 1, column 354 to line 1, column 368: > Table 'lineitem_par100' not found > [d8aa2d68-c0eb-4bba-af6b-40403118c264 on ucs-node11.perf.lab:31010] > java.sql.SQLException: exception while executing query: Failure while > executing query. > at net.hydromatic.avatica.Helper.createException(Helper.java:40) > at > net.hydromatic.avatica.AvaticaConnection.executeQueryInternal(AvaticaConnection.java:406) > at > net.hydromatic.avatica.AvaticaStatement.executeQueryInternal(AvaticaStatement.java:351) > at > net.hydromatic.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:78) > at > org.apache.drill.jdbc.DrillStatement.executeQuery(DrillStatement.java:60) > at PipSQueak.executeQuery(PipSQueak.java:251) > at PipSQueak.runTest(PipSQueak.java:79) > at PipSQueak.main(PipSQueak.java:430) > Caused by: java.sql.SQLException: Failure while executing query. > at org.apache.drill.jdbc.DrillCursor.next(DrillCursor.java:147) > at > org.apache.drill.jdbc.impl.DrillResultSetImpl.execute(DrillResultSetImpl.java:144) > at > org.apache.drill.jdbc.impl.DrillResultSetImpl.execute(DrillResultSetImpl.java:57) > at > net.hydromatic.avatica.AvaticaConnection.executeQueryInternal(AvaticaConnection.java:404) > ... 6 more > Caused by: org.apache.drill.common.exceptions.UserRemoteException: PARSE > ERROR: From line 1, column 354 to line 1, column 368: Table 'lineitem_par100' > not found > [d8aa2d68-c0eb-4bba-af6b-40403118c264 on ucs-node11.perf.lab:31010] > at > org.apache.drill.exec.rpc.user.QueryResultHandler.resultArrived(QueryResultHandler.java:112) > at > org.apache.drill.exec.rpc.user.UserClient.handleReponse(UserClient.java:102) > at > org.apache.drill.exec.rpc.BasicClientWithConnection.handle(BasicClientWithConnection.java:52) > at > org.apache.drill.exec.rpc.BasicClientWithConnection.handle(BasicClientWithConnection.java:34) > at org.apache.drill.exec.rpc.RpcBus.handle(RpcBus.java:57) > at > org.apache.drill.exec.rpc.RpcBus$InboundHandler.decode(RpcBus.java:194) > at > org.apache.drill.exec.rpc.RpcBus$InboundHandler.decode(RpcBus.java:173) > at > io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:89) > at > io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:333) > at > io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:319) > at > io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:103) > at > io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:333) > at > io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:319) > at > io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:161) > at > io.netty.channel.AbstractChanne
[jira] [Updated] (DRILL-2951) Tables are not visible when Drillbit is specified in the connection URL
[ https://issues.apache.org/jira/browse/DRILL-2951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Parth Chandra updated DRILL-2951: - Attachment: DRILL-2951.1.patch.diff > Tables are not visible when Drillbit is specified in the connection URL > --- > > Key: DRILL-2951 > URL: https://issues.apache.org/jira/browse/DRILL-2951 > Project: Apache Drill > Issue Type: Bug > Components: Client - JDBC >Affects Versions: 0.9.0 > Environment: RHEL 6.4 >Reporter: Kunal Khatua >Assignee: Parth Chandra >Priority: Blocker > Fix For: 1.0.0 > > Attachments: DRILL-2951.1.patch.diff > > > When running a query against a Drill cluster without specifying the drillbit, > the query executes correctly and without issue: > Connection Example: > [TestClient] -Dconn="jdbc:drill:schema=dfs.drill" PipSQueak 01_par100.q > [STAT] Query : > select l_returnflag, l_linestatus, sum(l_quantity) as sum_qty, > sum(l_extendedprice) as sum_base_price, sum(l_extendedprice * (1 - > l_discount)) as sum_disc_price, sum(l_extendedprice * (1 - l_discount) * (1 + > l_tax)) as sum_charge, avg(l_quantity) as avg_qty, avg(l_extendedprice) as > avg_price, avg(l_discount) as avg_disc, count(*) as count_order from > lineitem_par100 where l_shipdate <= date '1998-12-01' - interval '120' day > (3) group by l_returnflag, l_linestatus order by l_returnflag, l_linestatus > [STAT] Rows Fetched : 4 > [STAT] TOTAL TIME : 32142 msec > However, when the Drillbit is specified (even on the same Drillbit where the > query was previously submitted), we get a parse error: > Query failed: PARSE ERROR: From line 1, column 354 to line 1, column 368: > Table 'lineitem_par100' not found > [d8aa2d68-c0eb-4bba-af6b-40403118c264 on ucs-node11.perf.lab:31010] > java.sql.SQLException: exception while executing query: Failure while > executing query. > at net.hydromatic.avatica.Helper.createException(Helper.java:40) > at > net.hydromatic.avatica.AvaticaConnection.executeQueryInternal(AvaticaConnection.java:406) > at > net.hydromatic.avatica.AvaticaStatement.executeQueryInternal(AvaticaStatement.java:351) > at > net.hydromatic.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:78) > at > org.apache.drill.jdbc.DrillStatement.executeQuery(DrillStatement.java:60) > at PipSQueak.executeQuery(PipSQueak.java:251) > at PipSQueak.runTest(PipSQueak.java:79) > at PipSQueak.main(PipSQueak.java:430) > Caused by: java.sql.SQLException: Failure while executing query. > at org.apache.drill.jdbc.DrillCursor.next(DrillCursor.java:147) > at > org.apache.drill.jdbc.impl.DrillResultSetImpl.execute(DrillResultSetImpl.java:144) > at > org.apache.drill.jdbc.impl.DrillResultSetImpl.execute(DrillResultSetImpl.java:57) > at > net.hydromatic.avatica.AvaticaConnection.executeQueryInternal(AvaticaConnection.java:404) > ... 6 more > Caused by: org.apache.drill.common.exceptions.UserRemoteException: PARSE > ERROR: From line 1, column 354 to line 1, column 368: Table 'lineitem_par100' > not found > [d8aa2d68-c0eb-4bba-af6b-40403118c264 on ucs-node11.perf.lab:31010] > at > org.apache.drill.exec.rpc.user.QueryResultHandler.resultArrived(QueryResultHandler.java:112) > at > org.apache.drill.exec.rpc.user.UserClient.handleReponse(UserClient.java:102) > at > org.apache.drill.exec.rpc.BasicClientWithConnection.handle(BasicClientWithConnection.java:52) > at > org.apache.drill.exec.rpc.BasicClientWithConnection.handle(BasicClientWithConnection.java:34) > at org.apache.drill.exec.rpc.RpcBus.handle(RpcBus.java:57) > at > org.apache.drill.exec.rpc.RpcBus$InboundHandler.decode(RpcBus.java:194) > at > org.apache.drill.exec.rpc.RpcBus$InboundHandler.decode(RpcBus.java:173) > at > io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:89) > at > io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:333) > at > io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:319) > at > io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:103) > at > io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:333) > at > io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:319) > at > io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:161) > at > io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java
[jira] [Commented] (DRILL-2924) IOBException when querying a table which has 1 file and a subfolder with 1 file
[
https://issues.apache.org/jira/browse/DRILL-2924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14529471#comment-14529471
]
Daniel Barclay (Drill) commented on DRILL-2924:
---
Files (at least stripped-down versions) effectively had different schemas, so
moving to 1.2.
> IOBException when querying a table which has 1 file and a subfolder with 1
> file
> ---
>
> Key: DRILL-2924
> URL: https://issues.apache.org/jira/browse/DRILL-2924
> Project: Apache Drill
> Issue Type: Bug
> Components: Client - JDBC, Storage - JSON, Storage - Parquet
>Reporter: Rahul Challapalli
>Assignee: Daniel Barclay (Drill)
>Priority: Critical
> Fix For: 1.2.0
>
> Attachments: data1.tar, error.log
>
>
> git.commit.id.abbrev=5fbd274
> Below is the folder structure
> Data Structure :
> {code}
> data1
> -- a.json
> -- folder1
>-- b.json
> {code}
> Query :
> {code}
> 0: jdbc:drill:schema=dfs_eea> select * from `data1`;
> ++---+-+
> |dir0| executionTime | stationBeanList |
> ++---+-+
> | folder1| 2014-11-04 11:54:01 AM | [{"id":72,"stationName":"W 52 St & 11
> Ave", ..
> java.lang.IndexOutOfBoundsException: index: -4, length: 4 (expected: range(0,
> 4))
> at io.netty.buffer.DrillBuf.checkIndexD(DrillBuf.java:200)
> at io.netty.buffer.DrillBuf.chk(DrillBuf.java:222)
> at io.netty.buffer.DrillBuf.getInt(DrillBuf.java:500)
> at
> org.apache.drill.exec.vector.UInt4Vector$Accessor.get(UInt4Vector.java:299)
> at
> org.apache.drill.exec.vector.complex.RepeatedMapVector$RepeatedMapAccessor.getValueCount(RepeatedMapVector.java:470)
> at
> org.apache.drill.exec.vector.accessor.BoundCheckingAccessor.getObject(BoundCheckingAccessor.java:142)
> at
> org.apache.drill.jdbc.impl.TypeConvertingSqlAccessor.getObject(TypeConvertingSqlAccessor.java:790)
> at
> org.apache.drill.jdbc.AvaticaDrillSqlAccessor.getObject(AvaticaDrillSqlAccessor.java:165)
> at
> net.hydromatic.avatica.AvaticaResultSet.getObject(AvaticaResultSet.java:351)
> at sqlline.SqlLine$Rows$Row.(SqlLine.java:2388)
> at sqlline.SqlLine$IncrementalRows.hasNext(SqlLine.java:2504)
> at sqlline.SqlLine$TableOutputFormat.print(SqlLine.java:2148)
> at sqlline.SqlLine.print(SqlLine.java:1809)
> at sqlline.SqlLine$Commands.execute(SqlLine.java:3766)
> at sqlline.SqlLine$Commands.sql(SqlLine.java:3663)
> at sqlline.SqlLine.dispatch(SqlLine.java:889)
> at sqlline.SqlLine.begin(SqlLine.java:763)
> at sqlline.SqlLine.start(SqlLine.java:498)
> at sqlline.SqlLine.main(SqlLine.java:460)
> {code}
> I attached the error log and the data file. Let me know if you need anything
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DRILL-2924) IOBException when querying a table which has 1 file and a subfolder with 1 file
[
https://issues.apache.org/jira/browse/DRILL-2924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Barclay (Drill) updated DRILL-2924:
--
Fix Version/s: (was: 1.0.0)
1.2.0
> IOBException when querying a table which has 1 file and a subfolder with 1
> file
> ---
>
> Key: DRILL-2924
> URL: https://issues.apache.org/jira/browse/DRILL-2924
> Project: Apache Drill
> Issue Type: Bug
> Components: Client - JDBC, Storage - JSON, Storage - Parquet
>Reporter: Rahul Challapalli
>Assignee: Daniel Barclay (Drill)
>Priority: Critical
> Fix For: 1.2.0
>
> Attachments: data1.tar, error.log
>
>
> git.commit.id.abbrev=5fbd274
> Below is the folder structure
> Data Structure :
> {code}
> data1
> -- a.json
> -- folder1
>-- b.json
> {code}
> Query :
> {code}
> 0: jdbc:drill:schema=dfs_eea> select * from `data1`;
> ++---+-+
> |dir0| executionTime | stationBeanList |
> ++---+-+
> | folder1| 2014-11-04 11:54:01 AM | [{"id":72,"stationName":"W 52 St & 11
> Ave", ..
> java.lang.IndexOutOfBoundsException: index: -4, length: 4 (expected: range(0,
> 4))
> at io.netty.buffer.DrillBuf.checkIndexD(DrillBuf.java:200)
> at io.netty.buffer.DrillBuf.chk(DrillBuf.java:222)
> at io.netty.buffer.DrillBuf.getInt(DrillBuf.java:500)
> at
> org.apache.drill.exec.vector.UInt4Vector$Accessor.get(UInt4Vector.java:299)
> at
> org.apache.drill.exec.vector.complex.RepeatedMapVector$RepeatedMapAccessor.getValueCount(RepeatedMapVector.java:470)
> at
> org.apache.drill.exec.vector.accessor.BoundCheckingAccessor.getObject(BoundCheckingAccessor.java:142)
> at
> org.apache.drill.jdbc.impl.TypeConvertingSqlAccessor.getObject(TypeConvertingSqlAccessor.java:790)
> at
> org.apache.drill.jdbc.AvaticaDrillSqlAccessor.getObject(AvaticaDrillSqlAccessor.java:165)
> at
> net.hydromatic.avatica.AvaticaResultSet.getObject(AvaticaResultSet.java:351)
> at sqlline.SqlLine$Rows$Row.(SqlLine.java:2388)
> at sqlline.SqlLine$IncrementalRows.hasNext(SqlLine.java:2504)
> at sqlline.SqlLine$TableOutputFormat.print(SqlLine.java:2148)
> at sqlline.SqlLine.print(SqlLine.java:1809)
> at sqlline.SqlLine$Commands.execute(SqlLine.java:3766)
> at sqlline.SqlLine$Commands.sql(SqlLine.java:3663)
> at sqlline.SqlLine.dispatch(SqlLine.java:889)
> at sqlline.SqlLine.begin(SqlLine.java:763)
> at sqlline.SqlLine.start(SqlLine.java:498)
> at sqlline.SqlLine.main(SqlLine.java:460)
> {code}
> I attached the error log and the data file. Let me know if you need anything
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DRILL-1781) For complex functions, don't return until schema is known
[ https://issues.apache.org/jira/browse/DRILL-1781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14529462#comment-14529462 ] Krystal commented on DRILL-1781: Spoke to Steven regarding how to verify this bug. Basically run a query with a "convert_from" follow by a sort on any column. The schema should not come back right away and the returned data should be correct. > For complex functions, don't return until schema is known > - > > Key: DRILL-1781 > URL: https://issues.apache.org/jira/browse/DRILL-1781 > Project: Apache Drill > Issue Type: Bug > Components: Metadata >Reporter: Steven Phillips >Assignee: Chun Chang >Priority: Blocker > Fix For: 0.7.0 > > Attachments: DRILL-1781.patch, DRILL-1781.patch > > > In the case of complex output functions, it is impossible to determine the > output schema until the actual data is consumed. For example, with > convert_form(VARCHAR, 'json'), unlike most other functions, it is not > sufficient to know that the incoming data type is VARCHAR, we actually need > to decode the contents of the record before we can determine what the output > type is, whether it be map, list, or primitive type. > For fast schema return, we worked around this problem by simply assuming the > type was Map, and if it happened to be different, there would be a schema > change. This solution is not satisfactory, as it ends up breaking other > functions, like flatten. > The solution is to continue returning a schema whenever possible, but when it > is not possible, drill will wait until it is. > For non-blocking operators, drill will immediately consume the incoming > batch, and thus will not return empty schema batches if there is data to > consume. Blocking operators will return an empty schema batch. If a flattten > function occurs downstream from a blocking operator, it will not be able to > return a schema, and thus fast schema return will not happen in this case. > In the cases where the complex function is not downstream from a blocking > operator, fast schema return should continue to work. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (DRILL-1781) For complex functions, don't return until schema is known
[ https://issues.apache.org/jira/browse/DRILL-1781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chun Chang reassigned DRILL-1781: - Assignee: Chun Chang > For complex functions, don't return until schema is known > - > > Key: DRILL-1781 > URL: https://issues.apache.org/jira/browse/DRILL-1781 > Project: Apache Drill > Issue Type: Bug > Components: Metadata >Reporter: Steven Phillips >Assignee: Chun Chang >Priority: Blocker > Fix For: 0.7.0 > > Attachments: DRILL-1781.patch, DRILL-1781.patch > > > In the case of complex output functions, it is impossible to determine the > output schema until the actual data is consumed. For example, with > convert_form(VARCHAR, 'json'), unlike most other functions, it is not > sufficient to know that the incoming data type is VARCHAR, we actually need > to decode the contents of the record before we can determine what the output > type is, whether it be map, list, or primitive type. > For fast schema return, we worked around this problem by simply assuming the > type was Map, and if it happened to be different, there would be a schema > change. This solution is not satisfactory, as it ends up breaking other > functions, like flatten. > The solution is to continue returning a schema whenever possible, but when it > is not possible, drill will wait until it is. > For non-blocking operators, drill will immediately consume the incoming > batch, and thus will not return empty schema batches if there is data to > consume. Blocking operators will return an empty schema batch. If a flattten > function occurs downstream from a blocking operator, it will not be able to > return a schema, and thus fast schema return will not happen in this case. > In the cases where the complex function is not downstream from a blocking > operator, fast schema return should continue to work. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-2914) regression: Mondrian query534.q, drill give wrong result
[
https://issues.apache.org/jira/browse/DRILL-2914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinfeng Ni updated DRILL-2914:
--
Assignee: Sean Hsuan-Yi Chu (was: Jinfeng Ni)
> regression: Mondrian query534.q, drill give wrong result
>
>
> Key: DRILL-2914
> URL: https://issues.apache.org/jira/browse/DRILL-2914
> Project: Apache Drill
> Issue Type: Bug
> Components: Query Planning & Optimization
>Affects Versions: 0.9.0
>Reporter: Chun Chang
>Assignee: Sean Hsuan-Yi Chu
>Priority: Critical
> Fix For: 1.0.0
>
> Attachments: customer
>
>
> #Wed Apr 29 14:39:22 EDT 2015
> git.commit.id.abbrev=f5b0f49
> Running mondrian tests and noticed several regressions. This one is related
> to group by with select * subquery.
> {code}
> SELECT gender2.gender AS c0
> FROM (SELECT *
> FROM customer) AS gender2
> GROUP BY gender2.gender
> ORDER BY gender2.gender ASC nulls last;
> {code}
> Correct result from postgres:
> {code}
> foodmart=# select gender2.gender as c0 from (SELECT * FROM customer) as
> gender2 group by gender2.gender order by gender2.gender ASC NULLS LAST;
> c0
>
> F
> M
> (2 rows)
> {code}
> Wrong result from drill:
> {code}
> 0: jdbc:drill:schema=dfs.drillTestDirAdvanced> select gender2.gender as c0
> from (SELECT * FROM customer) as gender2 group by gender2.gender order by
> gender2.gender ASC NULLS LAST;
> ++
> | c0 |
> ++
> | null |
> ++
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DRILL-2964) toString of JDBC object return type should do smarter JSON encoding
[
https://issues.apache.org/jira/browse/DRILL-2964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacques Nadeau updated DRILL-2964:
--
Assignee: Mehant Baid (was: Steven Phillips)
> toString of JDBC object return type should do smarter JSON encoding
> ---
>
> Key: DRILL-2964
> URL: https://issues.apache.org/jira/browse/DRILL-2964
> Project: Apache Drill
> Issue Type: Bug
> Components: Client - CLI
>Reporter: Rahul Challapalli
>Assignee: Mehant Baid
> Fix For: 1.2.0
>
>
> git.commit.id.abbrev=f240ac2
> Data :
> {code}
> {
> "int_col" : {"$numberLong": 1},
> "date_col" : {"$dateDay": "2012-05-22"},
> "time_col" : {"$time": "19:20:30.45Z"},
> "date_array" : [{"$dateDay" : "2012-08-01"}, {"$dateDay" : "2033-11-28"}],
> "time_array" : [{"$time": "19:20:30.45Z"}, {"$time": "11:25:01.45Z"}],
> "int_array" : [{"$numberLong": 1}, {"$numberLong": 2}, {"$numberLong": 3}]
> }
> {code}
> Query :
> {code}
> 0: jdbc:drill:schema=dfs_eea> select time_array, date_array from `data1.json`;
> +++
> | time_array | date_array |
> +++
> |
> [{"dayOfMonth":1,"dayOfWeek":4,"era":1,"year":1970,"dayOfYear":1,"centuryOfEra":19,"millisOfSecond":450,"millisOfDay":69630450,"secondOfMinute":30,"secondOfDay":69630,"minuteOfHour":20,"minuteOfDay":1160,"hourOfDay":19,"weekOfWeekyear":1,"weekyear":1970,"monthOfYear":1,"yearOfEra":1970,"yearOfCentury":70,"zone":{"fixed":true,"id":"UTC"},"millis":69630450,"chronology":{"zone":{"fixed":true,"id":"UTC"}},"afterNow":false,"equalNow":false,"beforeNow":true},{"dayOfMonth":1,"dayOfWeek":4,"era":1,"year":1970,"dayOfYear":1,"centuryOfEra":19,"millisOfSecond":450,"millisOfDay":41101450,"secondOfMinute":1,"secondOfDay":41101,"minuteOfHour":25,"minuteOfDay":685,"hourOfDay":11,"weekOfWeekyear":1,"weekyear":1970,"monthOfYear":1,"yearOfEra":1970,"yearOfCentury":70,"zone":{"fixed":true,"id":"UTC"},"millis":41101450,"chronology":{"zone":{"fixed":true,"id":"UTC"}},"afterNow":false,"equalNow":false,"beforeNow":true}]
> |
> [{"dayOfMonth":1,"dayOfWeek":3,"era":1,"year":2012,"dayOfYear":214,"centuryOfEra":20,"millisOfSecond":0,"millisOfDay":0,"secondOfMinute":0,"secondOfDay":0,"minuteOfHour":0,"minuteOfDay":0,"hourOfDay":0,"weekOfWeekyear":31,"weekyear":2012,"monthOfYear":8,"yearOfEra":2012,"yearOfCentury":12,"zone":{"fixed":true,"id":"UTC"},"millis":134377920,"chronology":{"zone":{"fixed":true,"id":"UTC"}},"afterNow":false,"equalNow":false,"beforeNow":true},{"dayOfMonth":28,"dayOfWeek":1,"era":1,"year":2033,"dayOfYear":332,"centuryOfEra":20,"millisOfSecond":0,"millisOfDay":0,"secondOfMinute":0,"secondOfDay":0,"minuteOfHour":0,"minuteOfDay":0,"hourOfDay":0,"weekOfWeekyear":48,"weekyear":2033,"monthOfYear":11,"yearOfEra":2033,"yearOfCentury":33,"zone":{"fixed":true,"id":"UTC"},"millis":201674880,"chronology":{"zone":{"fixed":true,"id":"UTC"}},"afterNow":true,"equalNow":false,"beforeNow":false}]
> |
> {code}
> Drill could be serializing the whole date object here. Marked it as critical
> since we are reporting wrong data. Let me know if you have any questions.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DRILL-2964) toString of JDBC object return type should do smarter JSON encoding
[
https://issues.apache.org/jira/browse/DRILL-2964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14529425#comment-14529425
]
Jacques Nadeau commented on DRILL-2964:
---
The problem here is actually SQLLine not knowing how to decode complex values.
We can improve by changing toString but the real problem is we need to
customize SQLline to have more data return modes.
> toString of JDBC object return type should do smarter JSON encoding
> ---
>
> Key: DRILL-2964
> URL: https://issues.apache.org/jira/browse/DRILL-2964
> Project: Apache Drill
> Issue Type: Bug
> Components: Client - CLI
>Reporter: Rahul Challapalli
>Assignee: Steven Phillips
> Fix For: 1.2.0
>
>
> git.commit.id.abbrev=f240ac2
> Data :
> {code}
> {
> "int_col" : {"$numberLong": 1},
> "date_col" : {"$dateDay": "2012-05-22"},
> "time_col" : {"$time": "19:20:30.45Z"},
> "date_array" : [{"$dateDay" : "2012-08-01"}, {"$dateDay" : "2033-11-28"}],
> "time_array" : [{"$time": "19:20:30.45Z"}, {"$time": "11:25:01.45Z"}],
> "int_array" : [{"$numberLong": 1}, {"$numberLong": 2}, {"$numberLong": 3}]
> }
> {code}
> Query :
> {code}
> 0: jdbc:drill:schema=dfs_eea> select time_array, date_array from `data1.json`;
> +++
> | time_array | date_array |
> +++
> |
> [{"dayOfMonth":1,"dayOfWeek":4,"era":1,"year":1970,"dayOfYear":1,"centuryOfEra":19,"millisOfSecond":450,"millisOfDay":69630450,"secondOfMinute":30,"secondOfDay":69630,"minuteOfHour":20,"minuteOfDay":1160,"hourOfDay":19,"weekOfWeekyear":1,"weekyear":1970,"monthOfYear":1,"yearOfEra":1970,"yearOfCentury":70,"zone":{"fixed":true,"id":"UTC"},"millis":69630450,"chronology":{"zone":{"fixed":true,"id":"UTC"}},"afterNow":false,"equalNow":false,"beforeNow":true},{"dayOfMonth":1,"dayOfWeek":4,"era":1,"year":1970,"dayOfYear":1,"centuryOfEra":19,"millisOfSecond":450,"millisOfDay":41101450,"secondOfMinute":1,"secondOfDay":41101,"minuteOfHour":25,"minuteOfDay":685,"hourOfDay":11,"weekOfWeekyear":1,"weekyear":1970,"monthOfYear":1,"yearOfEra":1970,"yearOfCentury":70,"zone":{"fixed":true,"id":"UTC"},"millis":41101450,"chronology":{"zone":{"fixed":true,"id":"UTC"}},"afterNow":false,"equalNow":false,"beforeNow":true}]
> |
> [{"dayOfMonth":1,"dayOfWeek":3,"era":1,"year":2012,"dayOfYear":214,"centuryOfEra":20,"millisOfSecond":0,"millisOfDay":0,"secondOfMinute":0,"secondOfDay":0,"minuteOfHour":0,"minuteOfDay":0,"hourOfDay":0,"weekOfWeekyear":31,"weekyear":2012,"monthOfYear":8,"yearOfEra":2012,"yearOfCentury":12,"zone":{"fixed":true,"id":"UTC"},"millis":134377920,"chronology":{"zone":{"fixed":true,"id":"UTC"}},"afterNow":false,"equalNow":false,"beforeNow":true},{"dayOfMonth":28,"dayOfWeek":1,"era":1,"year":2033,"dayOfYear":332,"centuryOfEra":20,"millisOfSecond":0,"millisOfDay":0,"secondOfMinute":0,"secondOfDay":0,"minuteOfHour":0,"minuteOfDay":0,"hourOfDay":0,"weekOfWeekyear":48,"weekyear":2033,"monthOfYear":11,"yearOfEra":2033,"yearOfCentury":33,"zone":{"fixed":true,"id":"UTC"},"millis":201674880,"chronology":{"zone":{"fixed":true,"id":"UTC"}},"afterNow":true,"equalNow":false,"beforeNow":false}]
> |
> {code}
> Drill could be serializing the whole date object here. Marked it as critical
> since we are reporting wrong data. Let me know if you have any questions.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DRILL-2964) toString of JDBC object return type should do smarter JSON encoding
[
https://issues.apache.org/jira/browse/DRILL-2964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacques Nadeau updated DRILL-2964:
--
Summary: toString of JDBC object return type should do smarter JSON
encoding (was: Extended Json : Repeated date and time columns reporting wrong
values)
> toString of JDBC object return type should do smarter JSON encoding
> ---
>
> Key: DRILL-2964
> URL: https://issues.apache.org/jira/browse/DRILL-2964
> Project: Apache Drill
> Issue Type: Bug
> Components: Client - CLI
>Reporter: Rahul Challapalli
>Assignee: Steven Phillips
> Fix For: 1.2.0
>
>
> git.commit.id.abbrev=f240ac2
> Data :
> {code}
> {
> "int_col" : {"$numberLong": 1},
> "date_col" : {"$dateDay": "2012-05-22"},
> "time_col" : {"$time": "19:20:30.45Z"},
> "date_array" : [{"$dateDay" : "2012-08-01"}, {"$dateDay" : "2033-11-28"}],
> "time_array" : [{"$time": "19:20:30.45Z"}, {"$time": "11:25:01.45Z"}],
> "int_array" : [{"$numberLong": 1}, {"$numberLong": 2}, {"$numberLong": 3}]
> }
> {code}
> Query :
> {code}
> 0: jdbc:drill:schema=dfs_eea> select time_array, date_array from `data1.json`;
> +++
> | time_array | date_array |
> +++
> |
> [{"dayOfMonth":1,"dayOfWeek":4,"era":1,"year":1970,"dayOfYear":1,"centuryOfEra":19,"millisOfSecond":450,"millisOfDay":69630450,"secondOfMinute":30,"secondOfDay":69630,"minuteOfHour":20,"minuteOfDay":1160,"hourOfDay":19,"weekOfWeekyear":1,"weekyear":1970,"monthOfYear":1,"yearOfEra":1970,"yearOfCentury":70,"zone":{"fixed":true,"id":"UTC"},"millis":69630450,"chronology":{"zone":{"fixed":true,"id":"UTC"}},"afterNow":false,"equalNow":false,"beforeNow":true},{"dayOfMonth":1,"dayOfWeek":4,"era":1,"year":1970,"dayOfYear":1,"centuryOfEra":19,"millisOfSecond":450,"millisOfDay":41101450,"secondOfMinute":1,"secondOfDay":41101,"minuteOfHour":25,"minuteOfDay":685,"hourOfDay":11,"weekOfWeekyear":1,"weekyear":1970,"monthOfYear":1,"yearOfEra":1970,"yearOfCentury":70,"zone":{"fixed":true,"id":"UTC"},"millis":41101450,"chronology":{"zone":{"fixed":true,"id":"UTC"}},"afterNow":false,"equalNow":false,"beforeNow":true}]
> |
> [{"dayOfMonth":1,"dayOfWeek":3,"era":1,"year":2012,"dayOfYear":214,"centuryOfEra":20,"millisOfSecond":0,"millisOfDay":0,"secondOfMinute":0,"secondOfDay":0,"minuteOfHour":0,"minuteOfDay":0,"hourOfDay":0,"weekOfWeekyear":31,"weekyear":2012,"monthOfYear":8,"yearOfEra":2012,"yearOfCentury":12,"zone":{"fixed":true,"id":"UTC"},"millis":134377920,"chronology":{"zone":{"fixed":true,"id":"UTC"}},"afterNow":false,"equalNow":false,"beforeNow":true},{"dayOfMonth":28,"dayOfWeek":1,"era":1,"year":2033,"dayOfYear":332,"centuryOfEra":20,"millisOfSecond":0,"millisOfDay":0,"secondOfMinute":0,"secondOfDay":0,"minuteOfHour":0,"minuteOfDay":0,"hourOfDay":0,"weekOfWeekyear":48,"weekyear":2033,"monthOfYear":11,"yearOfEra":2033,"yearOfCentury":33,"zone":{"fixed":true,"id":"UTC"},"millis":201674880,"chronology":{"zone":{"fixed":true,"id":"UTC"}},"afterNow":true,"equalNow":false,"beforeNow":false}]
> |
> {code}
> Drill could be serializing the whole date object here. Marked it as critical
> since we are reporting wrong data. Let me know if you have any questions.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DRILL-2964) Extended Json : Repeated date and time columns reporting wrong values
[
https://issues.apache.org/jira/browse/DRILL-2964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacques Nadeau updated DRILL-2964:
--
Component/s: (was: Storage - JSON)
Client - CLI
> Extended Json : Repeated date and time columns reporting wrong values
> -
>
> Key: DRILL-2964
> URL: https://issues.apache.org/jira/browse/DRILL-2964
> Project: Apache Drill
> Issue Type: Bug
> Components: Client - CLI
>Reporter: Rahul Challapalli
>Assignee: Steven Phillips
> Fix For: 1.2.0
>
>
> git.commit.id.abbrev=f240ac2
> Data :
> {code}
> {
> "int_col" : {"$numberLong": 1},
> "date_col" : {"$dateDay": "2012-05-22"},
> "time_col" : {"$time": "19:20:30.45Z"},
> "date_array" : [{"$dateDay" : "2012-08-01"}, {"$dateDay" : "2033-11-28"}],
> "time_array" : [{"$time": "19:20:30.45Z"}, {"$time": "11:25:01.45Z"}],
> "int_array" : [{"$numberLong": 1}, {"$numberLong": 2}, {"$numberLong": 3}]
> }
> {code}
> Query :
> {code}
> 0: jdbc:drill:schema=dfs_eea> select time_array, date_array from `data1.json`;
> +++
> | time_array | date_array |
> +++
> |
> [{"dayOfMonth":1,"dayOfWeek":4,"era":1,"year":1970,"dayOfYear":1,"centuryOfEra":19,"millisOfSecond":450,"millisOfDay":69630450,"secondOfMinute":30,"secondOfDay":69630,"minuteOfHour":20,"minuteOfDay":1160,"hourOfDay":19,"weekOfWeekyear":1,"weekyear":1970,"monthOfYear":1,"yearOfEra":1970,"yearOfCentury":70,"zone":{"fixed":true,"id":"UTC"},"millis":69630450,"chronology":{"zone":{"fixed":true,"id":"UTC"}},"afterNow":false,"equalNow":false,"beforeNow":true},{"dayOfMonth":1,"dayOfWeek":4,"era":1,"year":1970,"dayOfYear":1,"centuryOfEra":19,"millisOfSecond":450,"millisOfDay":41101450,"secondOfMinute":1,"secondOfDay":41101,"minuteOfHour":25,"minuteOfDay":685,"hourOfDay":11,"weekOfWeekyear":1,"weekyear":1970,"monthOfYear":1,"yearOfEra":1970,"yearOfCentury":70,"zone":{"fixed":true,"id":"UTC"},"millis":41101450,"chronology":{"zone":{"fixed":true,"id":"UTC"}},"afterNow":false,"equalNow":false,"beforeNow":true}]
> |
> [{"dayOfMonth":1,"dayOfWeek":3,"era":1,"year":2012,"dayOfYear":214,"centuryOfEra":20,"millisOfSecond":0,"millisOfDay":0,"secondOfMinute":0,"secondOfDay":0,"minuteOfHour":0,"minuteOfDay":0,"hourOfDay":0,"weekOfWeekyear":31,"weekyear":2012,"monthOfYear":8,"yearOfEra":2012,"yearOfCentury":12,"zone":{"fixed":true,"id":"UTC"},"millis":134377920,"chronology":{"zone":{"fixed":true,"id":"UTC"}},"afterNow":false,"equalNow":false,"beforeNow":true},{"dayOfMonth":28,"dayOfWeek":1,"era":1,"year":2033,"dayOfYear":332,"centuryOfEra":20,"millisOfSecond":0,"millisOfDay":0,"secondOfMinute":0,"secondOfDay":0,"minuteOfHour":0,"minuteOfDay":0,"hourOfDay":0,"weekOfWeekyear":48,"weekyear":2033,"monthOfYear":11,"yearOfEra":2033,"yearOfCentury":33,"zone":{"fixed":true,"id":"UTC"},"millis":201674880,"chronology":{"zone":{"fixed":true,"id":"UTC"}},"afterNow":true,"equalNow":false,"beforeNow":false}]
> |
> {code}
> Drill could be serializing the whole date object here. Marked it as critical
> since we are reporting wrong data. Let me know if you have any questions.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DRILL-2964) Extended Json : Repeated date and time columns reporting wrong values
[
https://issues.apache.org/jira/browse/DRILL-2964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacques Nadeau updated DRILL-2964:
--
Priority: Major (was: Critical)
> Extended Json : Repeated date and time columns reporting wrong values
> -
>
> Key: DRILL-2964
> URL: https://issues.apache.org/jira/browse/DRILL-2964
> Project: Apache Drill
> Issue Type: Bug
> Components: Client - CLI
>Reporter: Rahul Challapalli
>Assignee: Steven Phillips
> Fix For: 1.2.0
>
>
> git.commit.id.abbrev=f240ac2
> Data :
> {code}
> {
> "int_col" : {"$numberLong": 1},
> "date_col" : {"$dateDay": "2012-05-22"},
> "time_col" : {"$time": "19:20:30.45Z"},
> "date_array" : [{"$dateDay" : "2012-08-01"}, {"$dateDay" : "2033-11-28"}],
> "time_array" : [{"$time": "19:20:30.45Z"}, {"$time": "11:25:01.45Z"}],
> "int_array" : [{"$numberLong": 1}, {"$numberLong": 2}, {"$numberLong": 3}]
> }
> {code}
> Query :
> {code}
> 0: jdbc:drill:schema=dfs_eea> select time_array, date_array from `data1.json`;
> +++
> | time_array | date_array |
> +++
> |
> [{"dayOfMonth":1,"dayOfWeek":4,"era":1,"year":1970,"dayOfYear":1,"centuryOfEra":19,"millisOfSecond":450,"millisOfDay":69630450,"secondOfMinute":30,"secondOfDay":69630,"minuteOfHour":20,"minuteOfDay":1160,"hourOfDay":19,"weekOfWeekyear":1,"weekyear":1970,"monthOfYear":1,"yearOfEra":1970,"yearOfCentury":70,"zone":{"fixed":true,"id":"UTC"},"millis":69630450,"chronology":{"zone":{"fixed":true,"id":"UTC"}},"afterNow":false,"equalNow":false,"beforeNow":true},{"dayOfMonth":1,"dayOfWeek":4,"era":1,"year":1970,"dayOfYear":1,"centuryOfEra":19,"millisOfSecond":450,"millisOfDay":41101450,"secondOfMinute":1,"secondOfDay":41101,"minuteOfHour":25,"minuteOfDay":685,"hourOfDay":11,"weekOfWeekyear":1,"weekyear":1970,"monthOfYear":1,"yearOfEra":1970,"yearOfCentury":70,"zone":{"fixed":true,"id":"UTC"},"millis":41101450,"chronology":{"zone":{"fixed":true,"id":"UTC"}},"afterNow":false,"equalNow":false,"beforeNow":true}]
> |
> [{"dayOfMonth":1,"dayOfWeek":3,"era":1,"year":2012,"dayOfYear":214,"centuryOfEra":20,"millisOfSecond":0,"millisOfDay":0,"secondOfMinute":0,"secondOfDay":0,"minuteOfHour":0,"minuteOfDay":0,"hourOfDay":0,"weekOfWeekyear":31,"weekyear":2012,"monthOfYear":8,"yearOfEra":2012,"yearOfCentury":12,"zone":{"fixed":true,"id":"UTC"},"millis":134377920,"chronology":{"zone":{"fixed":true,"id":"UTC"}},"afterNow":false,"equalNow":false,"beforeNow":true},{"dayOfMonth":28,"dayOfWeek":1,"era":1,"year":2033,"dayOfYear":332,"centuryOfEra":20,"millisOfSecond":0,"millisOfDay":0,"secondOfMinute":0,"secondOfDay":0,"minuteOfHour":0,"minuteOfDay":0,"hourOfDay":0,"weekOfWeekyear":48,"weekyear":2033,"monthOfYear":11,"yearOfEra":2033,"yearOfCentury":33,"zone":{"fixed":true,"id":"UTC"},"millis":201674880,"chronology":{"zone":{"fixed":true,"id":"UTC"}},"afterNow":true,"equalNow":false,"beforeNow":false}]
> |
> {code}
> Drill could be serializing the whole date object here. Marked it as critical
> since we are reporting wrong data. Let me know if you have any questions.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DRILL-2964) Extended Json : Repeated date and time columns reporting wrong values
[
https://issues.apache.org/jira/browse/DRILL-2964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacques Nadeau updated DRILL-2964:
--
Fix Version/s: 1.2.0
> Extended Json : Repeated date and time columns reporting wrong values
> -
>
> Key: DRILL-2964
> URL: https://issues.apache.org/jira/browse/DRILL-2964
> Project: Apache Drill
> Issue Type: Bug
> Components: Client - CLI
>Reporter: Rahul Challapalli
>Assignee: Steven Phillips
> Fix For: 1.2.0
>
>
> git.commit.id.abbrev=f240ac2
> Data :
> {code}
> {
> "int_col" : {"$numberLong": 1},
> "date_col" : {"$dateDay": "2012-05-22"},
> "time_col" : {"$time": "19:20:30.45Z"},
> "date_array" : [{"$dateDay" : "2012-08-01"}, {"$dateDay" : "2033-11-28"}],
> "time_array" : [{"$time": "19:20:30.45Z"}, {"$time": "11:25:01.45Z"}],
> "int_array" : [{"$numberLong": 1}, {"$numberLong": 2}, {"$numberLong": 3}]
> }
> {code}
> Query :
> {code}
> 0: jdbc:drill:schema=dfs_eea> select time_array, date_array from `data1.json`;
> +++
> | time_array | date_array |
> +++
> |
> [{"dayOfMonth":1,"dayOfWeek":4,"era":1,"year":1970,"dayOfYear":1,"centuryOfEra":19,"millisOfSecond":450,"millisOfDay":69630450,"secondOfMinute":30,"secondOfDay":69630,"minuteOfHour":20,"minuteOfDay":1160,"hourOfDay":19,"weekOfWeekyear":1,"weekyear":1970,"monthOfYear":1,"yearOfEra":1970,"yearOfCentury":70,"zone":{"fixed":true,"id":"UTC"},"millis":69630450,"chronology":{"zone":{"fixed":true,"id":"UTC"}},"afterNow":false,"equalNow":false,"beforeNow":true},{"dayOfMonth":1,"dayOfWeek":4,"era":1,"year":1970,"dayOfYear":1,"centuryOfEra":19,"millisOfSecond":450,"millisOfDay":41101450,"secondOfMinute":1,"secondOfDay":41101,"minuteOfHour":25,"minuteOfDay":685,"hourOfDay":11,"weekOfWeekyear":1,"weekyear":1970,"monthOfYear":1,"yearOfEra":1970,"yearOfCentury":70,"zone":{"fixed":true,"id":"UTC"},"millis":41101450,"chronology":{"zone":{"fixed":true,"id":"UTC"}},"afterNow":false,"equalNow":false,"beforeNow":true}]
> |
> [{"dayOfMonth":1,"dayOfWeek":3,"era":1,"year":2012,"dayOfYear":214,"centuryOfEra":20,"millisOfSecond":0,"millisOfDay":0,"secondOfMinute":0,"secondOfDay":0,"minuteOfHour":0,"minuteOfDay":0,"hourOfDay":0,"weekOfWeekyear":31,"weekyear":2012,"monthOfYear":8,"yearOfEra":2012,"yearOfCentury":12,"zone":{"fixed":true,"id":"UTC"},"millis":134377920,"chronology":{"zone":{"fixed":true,"id":"UTC"}},"afterNow":false,"equalNow":false,"beforeNow":true},{"dayOfMonth":28,"dayOfWeek":1,"era":1,"year":2033,"dayOfYear":332,"centuryOfEra":20,"millisOfSecond":0,"millisOfDay":0,"secondOfMinute":0,"secondOfDay":0,"minuteOfHour":0,"minuteOfDay":0,"hourOfDay":0,"weekOfWeekyear":48,"weekyear":2033,"monthOfYear":11,"yearOfEra":2033,"yearOfCentury":33,"zone":{"fixed":true,"id":"UTC"},"millis":201674880,"chronology":{"zone":{"fixed":true,"id":"UTC"}},"afterNow":true,"equalNow":false,"beforeNow":false}]
> |
> {code}
> Drill could be serializing the whole date object here. Marked it as critical
> since we are reporting wrong data. Let me know if you have any questions.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DRILL-2906) Json reader with extended json adds extra column
[ https://issues.apache.org/jira/browse/DRILL-2906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14529379#comment-14529379 ] Jacques Nadeau commented on DRILL-2906: --- Let's just set default extended to off for now and resolve this in a future release. > Json reader with extended json adds extra column > > > Key: DRILL-2906 > URL: https://issues.apache.org/jira/browse/DRILL-2906 > Project: Apache Drill > Issue Type: Bug > Components: Storage - JSON, Storage - Writer >Reporter: Mehant Baid >Assignee: Steven Phillips > Fix For: 1.0.0 > > > Performing a CTAS with 'store.format' = 'json' and querying the table results > in projecting an addition field '*' will null values. Below is a simple repro > 0: jdbc:drill:zk=local> create table t as select timestamp '1980-10-01 > 00:00:00' from cp.`employee.json` limit 1; > ++---+ > | Fragment | Number of records written | > ++---+ > | 0_0| 1 | > ++---+ > 1 row selected (0.314 seconds) > 0: jdbc:drill:zk=local> select * from t; > +++ > | EXPR$0 | * | > +++ > | 1980-10-01 00:00:00.0 | null | > +++ > Notice in the above result set we get an extra column '*' with null value. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (DRILL-2069) Star is not expanded correctly in the query with IN clause containing subquery
[
https://issues.apache.org/jira/browse/DRILL-2069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Victoria Markman closed DRILL-2069.
---
> Star is not expanded correctly in the query with IN clause containing subquery
> --
>
> Key: DRILL-2069
> URL: https://issues.apache.org/jira/browse/DRILL-2069
> Project: Apache Drill
> Issue Type: Bug
> Components: Query Planning & Optimization
>Affects Versions: 0.8.0
>Reporter: Victoria Markman
>Assignee: Jinfeng Ni
>Priority: Critical
> Fix For: 0.8.0
>
> Attachments:
> 0001-DRILL-2069-Fix-star-query-prefix-logic-it-s-used-wit.patch
>
>
> t1.json
> {code}
> { "a1": "aa", "b1": 1 }
> { "a1": "bb", "b1": 2 }
> { "a1": "cc", "b1": 3 }
> {code}
> t2.json
> {code}
> { "a2": "aa", "b2": 1 }
> { "a2": "bb", "b2": 2 }
> { "a2": "xx", "b2": 10 }
> {code}
> Star is expanded incorrectly, we should get only columns from `t1.json`
> {code}
> 0: jdbc:drill:schema=dfs> select * from `t1.json` where a1 in (select a2 from
> `t2.json`);
> +++++
> | a2 | a1 | b1 |a10 |
> +++++
> | aa | aa | 1 | aa |
> | bb | bb | 2 | bb |
> +++++
> 2 rows selected (0.172 seconds)
> {code}
> explain plan
> {code}
> 00-01 Project(*=[$0])
> 00-02Project(*=[$0])
> 00-03 HashJoin(condition=[=($1, $2)], joinType=[inner])
> 00-05Project(*=[$0], a1=[$1])
> 00-07 Scan(groupscan=[EasyGroupScan
> [selectionRoot=/test/t1.json, numFiles=1, columns=[`*`],
> files=[maprfs:/test/t1.json]]])
> 00-04HashAgg(group=[{0}])
> 00-06 Scan(groupscan=[EasyGroupScan
> [selectionRoot=/test/t2.json, numFiles=1, columns=[`a2`],
> files=[maprfs:/test/t2.json]]])
> {code}
> Workaround - specify columns explicitly
> {code}
> 0: jdbc:drill:schema=dfs> select t1.a1, t1.a1 from `t1.json` t1 where t1.a1
> in (select t2.a2 from `t2.json` t2);
> +++
> | a1 |a10 |
> +++
> | aa | aa |
> | bb | bb |
> +++
> 2 rows selected (0.24 seconds)
> {code}
> Note to myself: include cases like below during verification:
> {code}
> 0: jdbc:drill:schema=dfs> select * from `t1.json` t1 where (a1, b1) in
> (select a2, b2 from `t2.json`);
> +++++++
> | a2 | b2 | a1 | b1 |a10 |b10
> |
> +++++++
> | aa | 1 | aa | 1 | aa | 1
> |
> | bb | 2 | bb | 2 | bb | 2
> |
> +++++++
> 2 rows selected (0.323 seconds)
> 0: jdbc:drill:schema=dfs> select * from `t1.json` t1 where (a1, b1) in
> (select * from `t2.json`);
> Query failed: SqlValidatorException: Values passed to IN operator must have
> compatible types
> Error: exception while executing query: Failure while executing query.
> (state=,code=0)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DRILL-2069) Star is not expanded correctly in the query with IN clause containing subquery
[
https://issues.apache.org/jira/browse/DRILL-2069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14529332#comment-14529332
]
Victoria Markman commented on DRILL-2069:
-
Verified fixed in 0.9.0
#Sun May 03 18:33:43 EDT 2015
git.commit.id.abbrev=10833d2
Functional/Passing/subqueries/bugs/drill-2069.sql
Functional/Passing/subqueries/bugs/drill-2069-with-alias.sql
> Star is not expanded correctly in the query with IN clause containing subquery
> --
>
> Key: DRILL-2069
> URL: https://issues.apache.org/jira/browse/DRILL-2069
> Project: Apache Drill
> Issue Type: Bug
> Components: Query Planning & Optimization
>Affects Versions: 0.8.0
>Reporter: Victoria Markman
>Assignee: Jinfeng Ni
>Priority: Critical
> Fix For: 0.8.0
>
> Attachments:
> 0001-DRILL-2069-Fix-star-query-prefix-logic-it-s-used-wit.patch
>
>
> t1.json
> {code}
> { "a1": "aa", "b1": 1 }
> { "a1": "bb", "b1": 2 }
> { "a1": "cc", "b1": 3 }
> {code}
> t2.json
> {code}
> { "a2": "aa", "b2": 1 }
> { "a2": "bb", "b2": 2 }
> { "a2": "xx", "b2": 10 }
> {code}
> Star is expanded incorrectly, we should get only columns from `t1.json`
> {code}
> 0: jdbc:drill:schema=dfs> select * from `t1.json` where a1 in (select a2 from
> `t2.json`);
> +++++
> | a2 | a1 | b1 |a10 |
> +++++
> | aa | aa | 1 | aa |
> | bb | bb | 2 | bb |
> +++++
> 2 rows selected (0.172 seconds)
> {code}
> explain plan
> {code}
> 00-01 Project(*=[$0])
> 00-02Project(*=[$0])
> 00-03 HashJoin(condition=[=($1, $2)], joinType=[inner])
> 00-05Project(*=[$0], a1=[$1])
> 00-07 Scan(groupscan=[EasyGroupScan
> [selectionRoot=/test/t1.json, numFiles=1, columns=[`*`],
> files=[maprfs:/test/t1.json]]])
> 00-04HashAgg(group=[{0}])
> 00-06 Scan(groupscan=[EasyGroupScan
> [selectionRoot=/test/t2.json, numFiles=1, columns=[`a2`],
> files=[maprfs:/test/t2.json]]])
> {code}
> Workaround - specify columns explicitly
> {code}
> 0: jdbc:drill:schema=dfs> select t1.a1, t1.a1 from `t1.json` t1 where t1.a1
> in (select t2.a2 from `t2.json` t2);
> +++
> | a1 |a10 |
> +++
> | aa | aa |
> | bb | bb |
> +++
> 2 rows selected (0.24 seconds)
> {code}
> Note to myself: include cases like below during verification:
> {code}
> 0: jdbc:drill:schema=dfs> select * from `t1.json` t1 where (a1, b1) in
> (select a2, b2 from `t2.json`);
> +++++++
> | a2 | b2 | a1 | b1 |a10 |b10
> |
> +++++++
> | aa | 1 | aa | 1 | aa | 1
> |
> | bb | 2 | bb | 2 | bb | 2
> |
> +++++++
> 2 rows selected (0.323 seconds)
> 0: jdbc:drill:schema=dfs> select * from `t1.json` t1 where (a1, b1) in
> (select * from `t2.json`);
> Query failed: SqlValidatorException: Values passed to IN operator must have
> compatible types
> Error: exception while executing query: Failure while executing query.
> (state=,code=0)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DRILL-2906) Json reader with extended json adds extra column
[ https://issues.apache.org/jira/browse/DRILL-2906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steven Phillips updated DRILL-2906: --- Summary: Json reader with extended json adds extra column (was: CTAS with store.format = 'json' returns incorrect results) > Json reader with extended json adds extra column > > > Key: DRILL-2906 > URL: https://issues.apache.org/jira/browse/DRILL-2906 > Project: Apache Drill > Issue Type: Bug > Components: Storage - JSON, Storage - Writer >Reporter: Mehant Baid >Assignee: Steven Phillips > Fix For: 1.0.0 > > > Performing a CTAS with 'store.format' = 'json' and querying the table results > in projecting an addition field '*' will null values. Below is a simple repro > 0: jdbc:drill:zk=local> create table t as select timestamp '1980-10-01 > 00:00:00' from cp.`employee.json` limit 1; > ++---+ > | Fragment | Number of records written | > ++---+ > | 0_0| 1 | > ++---+ > 1 row selected (0.314 seconds) > 0: jdbc:drill:zk=local> select * from t; > +++ > | EXPR$0 | * | > +++ > | 1980-10-01 00:00:00.0 | null | > +++ > Notice in the above result set we get an extra column '*' with null value. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DRILL-2906) CTAS with store.format = 'json' returns incorrect results
[
https://issues.apache.org/jira/browse/DRILL-2906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14529331#comment-14529331
]
Steven Phillips commented on DRILL-2906:
This seems to be a problem with reading extended json, and is not related to
the writer.
For example, here are two files, where a.json uses extended json, but b.json
does not:
{code}
$ cat /tmp/a.json
{
"int_col" : {"$numberLong": 1},
"date_col" : {"$dateDay": "2012-05-22"},
"time_col" : {"$time": "19:20:30.45Z"}
}
$ cat /tmp/b.json
{
"int_col" : 1,
"date_col" : "2012-05-22",
"time_col" : "19:20:30.45Z"
}
{code}
Here is the output when querying:
{code}
0: jdbc:drill:> select * from dfs.tmp.`a.json`;
+++++
| int_col | date_col | time_col | * |
+++++
| 1 | 2012-05-22 | 11:20:30.450 | null |
+++++
1 row selected (1.477 seconds)
0: jdbc:drill:> select * from dfs.tmp.`b.json`;
++++
| int_col | date_col | time_col |
++++
| 1 | 2012-05-22 | 19:20:30.45Z |
++++
1 row selected (0.222 seconds)
{code}
> CTAS with store.format = 'json' returns incorrect results
> -
>
> Key: DRILL-2906
> URL: https://issues.apache.org/jira/browse/DRILL-2906
> Project: Apache Drill
> Issue Type: Bug
> Components: Storage - JSON, Storage - Writer
>Reporter: Mehant Baid
>Assignee: Steven Phillips
> Fix For: 1.0.0
>
>
> Performing a CTAS with 'store.format' = 'json' and querying the table results
> in projecting an addition field '*' will null values. Below is a simple repro
> 0: jdbc:drill:zk=local> create table t as select timestamp '1980-10-01
> 00:00:00' from cp.`employee.json` limit 1;
> ++---+
> | Fragment | Number of records written |
> ++---+
> | 0_0| 1 |
> ++---+
> 1 row selected (0.314 seconds)
> 0: jdbc:drill:zk=local> select * from t;
> +++
> | EXPR$0 | * |
> +++
> | 1980-10-01 00:00:00.0 | null |
> +++
> Notice in the above result set we get an extra column '*' with null value.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DRILL-2906) CTAS with store.format = 'json' returns incorrect results
[ https://issues.apache.org/jira/browse/DRILL-2906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14529321#comment-14529321 ] Mehant Baid commented on DRILL-2906: This happens in other cases as well (see below repro). However it only reproduces when the source is also in JSON format. 0: jdbc:drill:zk=local> create table t12 as select employee_id from cp.`employee.json` limit 1; ++---+ | Fragment | Number of records written | ++---+ | 0_0| 1 | ++---+ 1 row selected (0.208 seconds) 0: jdbc:drill:zk=local> select * from t12; +-++ | employee_id | * | +-++ | 1 | null | +-++ > CTAS with store.format = 'json' returns incorrect results > - > > Key: DRILL-2906 > URL: https://issues.apache.org/jira/browse/DRILL-2906 > Project: Apache Drill > Issue Type: Bug > Components: Storage - JSON, Storage - Writer >Reporter: Mehant Baid >Assignee: Steven Phillips > Fix For: 1.0.0 > > > Performing a CTAS with 'store.format' = 'json' and querying the table results > in projecting an addition field '*' will null values. Below is a simple repro > 0: jdbc:drill:zk=local> create table t as select timestamp '1980-10-01 > 00:00:00' from cp.`employee.json` limit 1; > ++---+ > | Fragment | Number of records written | > ++---+ > | 0_0| 1 | > ++---+ > 1 row selected (0.314 seconds) > 0: jdbc:drill:zk=local> select * from t; > +++ > | EXPR$0 | * | > +++ > | 1980-10-01 00:00:00.0 | null | > +++ > Notice in the above result set we get an extra column '*' with null value. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DRILL-2906) CTAS with store.format = 'json' returns incorrect results
[
https://issues.apache.org/jira/browse/DRILL-2906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14529303#comment-14529303
]
Rahul Challapalli commented on DRILL-2906:
--
This can be reproduced with a simpler case
Data :
{code}
{
"int_col" : {"$numberLong": 1},
"date_col" : {"$dateDay": "2012-05-22"},
"time_col" : {"$time": "19:20:30.45Z"}
}
{code}
Query :
{code}
0: jdbc:drill:schema=dfs_eea> select * from `temp.json`;
+++++
| int_col | date_col | time_col | * |
+++++
| 1 | 2012-05-22 | 19:20:30.450 | null |
+++++
1 row selected (0.147 seconds)
{code}
> CTAS with store.format = 'json' returns incorrect results
> -
>
> Key: DRILL-2906
> URL: https://issues.apache.org/jira/browse/DRILL-2906
> Project: Apache Drill
> Issue Type: Bug
> Components: Storage - JSON, Storage - Writer
>Reporter: Mehant Baid
>Assignee: Steven Phillips
> Fix For: 1.0.0
>
>
> Performing a CTAS with 'store.format' = 'json' and querying the table results
> in projecting an addition field '*' will null values. Below is a simple repro
> 0: jdbc:drill:zk=local> create table t as select timestamp '1980-10-01
> 00:00:00' from cp.`employee.json` limit 1;
> ++---+
> | Fragment | Number of records written |
> ++---+
> | 0_0| 1 |
> ++---+
> 1 row selected (0.314 seconds)
> 0: jdbc:drill:zk=local> select * from t;
> +++
> | EXPR$0 | * |
> +++
> | 1980-10-01 00:00:00.0 | null |
> +++
> Notice in the above result set we get an extra column '*' with null value.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DRILL-1289) Creating storage plugin for "hdfs:///" failed with "Unable to create/ update plugin: myhdfs"
[
https://issues.apache.org/jira/browse/DRILL-1289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Krystal updated DRILL-1289:
---
Component/s: (was: Metadata)
Client - HTTP
> Creating storage plugin for "hdfs:///" failed with "Unable to create/ update
> plugin: myhdfs"
>
>
> Key: DRILL-1289
> URL: https://issues.apache.org/jira/browse/DRILL-1289
> Project: Apache Drill
> Issue Type: Bug
> Components: Client - HTTP
>Affects Versions: 0.4.0
> Environment: OS: Centos 6.4
> HDFS: CDH5.1
> Drill: 0.4.0
>Reporter: Hao Zhu
> Fix For: 0.5.0
>
>
> In web GUI, I can successfully create a new storage plugin named "myhdfs"
> using "file:///":
> {code}
> {
> "type": "file",
> "enabled": true,
> "connection": "file:///",
> "workspaces": {
> "root": {
> "location": "/",
> "writable": false,
> "storageformat": null
> },
> "tmp": {
> "location": "/tmp",
> "writable": true,
> "storageformat": "csv"
> }
> },
> "formats": {
> "psv": {
> "type": "text",
> "extensions": [
> "tbl"
> ],
> "delimiter": "|"
> },
> "csv": {
> "type": "text",
> "extensions": [
> "csv"
> ],
> "delimiter": ","
> },
> "tsv": {
> "type": "text",
> "extensions": [
> "tsv"
> ],
> "delimiter": "\t"
> },
> "parquet": {
> "type": "parquet"
> },
> "json": {
> "type": "json"
> }
> }
> }
> {code}
> However if I try to change "file:///" to "hdfs:///" to point to HDFS other
> than local file system, drill log errors out "[qtp416200645-67] DEBUG
> o.a.d.e.server.rest.StorageResources - Unable to create/ update plugin:
> myhdfs".
> {code}
> {
> "type": "file",
> "enabled": true,
> "connection": "hdfs:///",
> "workspaces": {
> "root": {
> "location": "/",
> "writable": false,
> "storageformat": null
> },
> "tmp": {
> "location": "/tmp",
> "writable": true,
> "storageformat": "csv"
> }
> },
> "formats": {
> "psv": {
> "type": "text",
> "extensions": [
> "tbl"
> ],
> "delimiter": "|"
> },
> "csv": {
> "type": "text",
> "extensions": [
> "csv"
> ],
> "delimiter": ","
> },
> "tsv": {
> "type": "text",
> "extensions": [
> "tsv"
> ],
> "delimiter": "\t"
> },
> "parquet": {
> "type": "parquet"
> },
> "json": {
> "type": "json"
> }
> }
> }
> {code}
> On my cluster, I am using CDH5 hdfs, and it all client configurations are
> valid. For example, on the drillbit server:
> {code}
> [root@hdm ~]# hdfs dfs -ls /
> Found 3 items
> drwxr-xr-x - hbase hbase 0 2014-08-04 22:55 /hbase
> drwxrwxrwt - hdfs supergroup 0 2014-07-31 16:31 /tmp
> drwxr-xr-x - hdfs supergroup 0 2014-07-11 12:06 /user
> {code}
> Is there anything wrong with the storage plugin syntax for HDFS?
> If so, can drill log prints more debug info to show the reason why it failed?
> Thanks.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DRILL-1290) Document Configuration Steps for Different Hadoop Distributions
[
https://issues.apache.org/jira/browse/DRILL-1290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Krystal updated DRILL-1290:
---
Component/s: (was: Metadata)
Client - HTTP
> Document Configuration Steps for Different Hadoop Distributions
> ---
>
> Key: DRILL-1290
> URL: https://issues.apache.org/jira/browse/DRILL-1290
> Project: Apache Drill
> Issue Type: New Feature
> Components: Client - HTTP
> Environment: OS: Centos 6.4
> HDFS: CDH5.1
> Drill: 0.4.0
>Reporter: Hao Zhu
>Assignee: Neeraja
> Fix For: Future
>
>
> In web GUI, I can successfully create a new storage plugin named "myhdfs"
> using "file:///":
> {code}
> {
> "type": "file",
> "enabled": true,
> "connection": "file:///",
> "workspaces": {
> "root": {
> "location": "/",
> "writable": false,
> "storageformat": null
> },
> "tmp": {
> "location": "/tmp",
> "writable": true,
> "storageformat": "csv"
> }
> },
> "formats": {
> "psv": {
> "type": "text",
> "extensions": [
> "tbl"
> ],
> "delimiter": "|"
> },
> "csv": {
> "type": "text",
> "extensions": [
> "csv"
> ],
> "delimiter": ","
> },
> "tsv": {
> "type": "text",
> "extensions": [
> "tsv"
> ],
> "delimiter": "\t"
> },
> "parquet": {
> "type": "parquet"
> },
> "json": {
> "type": "json"
> }
> }
> }
> {code}
> However if I try to change "file:///" to "hdfs:///" to point to HDFS other
> than local file system, drill log errors out "[qtp416200645-67] DEBUG
> o.a.d.e.server.rest.StorageResources - Unable to create/ update plugin:
> myhdfs".
> {code}
> {
> "type": "file",
> "enabled": true,
> "connection": "hdfs:///",
> "workspaces": {
> "root": {
> "location": "/",
> "writable": false,
> "storageformat": null
> },
> "tmp": {
> "location": "/tmp",
> "writable": true,
> "storageformat": "csv"
> }
> },
> "formats": {
> "psv": {
> "type": "text",
> "extensions": [
> "tbl"
> ],
> "delimiter": "|"
> },
> "csv": {
> "type": "text",
> "extensions": [
> "csv"
> ],
> "delimiter": ","
> },
> "tsv": {
> "type": "text",
> "extensions": [
> "tsv"
> ],
> "delimiter": "\t"
> },
> "parquet": {
> "type": "parquet"
> },
> "json": {
> "type": "json"
> }
> }
> }
> {code}
> On my cluster, I am using CDH5 hdfs, and it all client configurations are
> valid. For example, on the drillbit server:
> {code}
> [root@hdm ~]# hdfs dfs -ls /
> Found 3 items
> drwxr-xr-x - hbase hbase 0 2014-08-04 22:55 /hbase
> drwxrwxrwt - hdfs supergroup 0 2014-07-31 16:31 /tmp
> drwxr-xr-x - hdfs supergroup 0 2014-07-11 12:06 /user
> {code}
> Is there anything wrong with the storage plugin syntax for HDFS?
> If so, can drill log prints more debug info to show the reason why it failed?
> Thanks.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DRILL-2602) Throw an error on schema change during streaming aggregation
[
https://issues.apache.org/jira/browse/DRILL-2602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Deneche A. Hakim updated DRILL-2602:
Attachment: DRILL-2602.1.patch.txt
updated both ExternalSortBatch and StreamAggBatch to throw a proper UNSUPPORTED
user exception.
Here is the output when using a Stream aggregate:
{noformat}
Query failed: UNSUPPORTED_OPERATION ERROR: Sort doesn't currently support sorts
with changing schemas
Fragment 0:0
[Error Id: 43fea1a6-1ae2-4c17-970e-8e168e347241 on 172.30.1.91:31010]
{noformat}
And here is the error message for a hash aggregate:
{noformat}
Query failed: UNSUPPORTED_OPERATION ERROR: Hash aggregate does not support
schema changes
Fragment 0:0
[Error Id: 6f849343-0a9d-4681-b101-17d7e1e32917 on 172.30.1.91:31010]
{noformat}
> Throw an error on schema change during streaming aggregation
>
>
> Key: DRILL-2602
> URL: https://issues.apache.org/jira/browse/DRILL-2602
> Project: Apache Drill
> Issue Type: Improvement
> Components: Execution - Relational Operators
>Affects Versions: 0.8.0
>Reporter: Victoria Markman
>Assignee: Deneche A. Hakim
> Fix For: 1.0.0
>
> Attachments: DRILL-2602.1.patch.txt, optional.parquet,
> required.parquet
>
>
> We don't recoginize schema change during streaming aggregation when column is
> a mix of required and optional types.
> Hash aggregation does throw correct error message.
> I have a table 'mix' where:
> {code}
> [Fri Mar 27 09:46:07 root@/mapr/vmarkman.cluster.com/drill/testdata/joins/mix
> ] # ls -ltr
> total 753
> -rwxr-xr-x 1 root root 759879 Mar 27 09:41 optional.parquet
> -rwxr-xr-x 1 root root 9867 Mar 27 09:41 required.parquet
> [Fri Mar 27 09:46:09 root@/mapr/vmarkman.cluster.com/drill/testdata/joins/mix
> ] # ~/parquet-tools-1.5.1-SNAPSHOT/parquet-schema optional.parquet
> message root {
> optional binary c_varchar (UTF8);
> optional int32 c_integer;
> optional int64 c_bigint;
> optional float c_float;
> optional double c_double;
> optional int32 c_date (DATE);
> optional int32 c_time (TIME);
> optional int64 c_timestamp (TIMESTAMP);
> optional boolean c_boolean;
> optional double d9;
> optional double d18;
> optional double d28;
> optional double d38;
> }
> [Fri Mar 27 09:46:41 root@/mapr/vmarkman.cluster.com/drill/testdata/joins/mix
> ] # ~/parquet-tools-1.5.1-SNAPSHOT/parquet-schema required.parquet
> message root {
> required binary c_varchar (UTF8);
> required int32 c_integer;
> required int64 c_bigint;
> required float c_float;
> required double c_double; required int32 c_date (DATE);
> required int32 c_time (TIME);
> required int64 c_timestamp (TIMESTAMP);
> required boolean c_boolean;
> required double d9;
> required double d18;
> required double d28;
> required double d38;
> }
> {code}
> Nice error message on hash aggregation:
> {code}
> 0: jdbc:drill:schema=dfs> select count(*) from mix group by c_integer;
> ++
> | EXPR$0 |
> ++
> Query failed: Query stopped., Hash aggregate does not support schema changes
> [ 2bc255ce-c7f9-47bf-80b0-a5c87cfa67be on atsqa4-134.qa.lab:31010 ]
> java.lang.RuntimeException: java.sql.SQLException: Failure while executing
> query.
> at sqlline.SqlLine$IncrementalRows.hasNext(SqlLine.java:2514)
> at sqlline.SqlLine$TableOutputFormat.print(SqlLine.java:2148)
> at sqlline.SqlLine.print(SqlLine.java:1809)
> at sqlline.SqlLine$Commands.execute(SqlLine.java:3766)
> at sqlline.SqlLine$Commands.sql(SqlLine.java:3663)
> at sqlline.SqlLine.dispatch(SqlLine.java:889)
> at sqlline.SqlLine.begin(SqlLine.java:763)
> at sqlline.SqlLine.start(SqlLine.java:498)
> at sqlline.SqlLine.main(SqlLine.java:460)
> {code}
> On streaming aggregation, exception that is hard for the end user to
> understand:
> {code}
> 0: jdbc:drill:schema=dfs> alter session set `planner.enable_hashagg` = false;
> +++
> | ok | summary |
> +++
> | true | planner.enable_hashagg updated. |
> +++
> 1 row selected (0.067 seconds)
> 0: jdbc:drill:schema=dfs> select count(*) from mix group by c_integer;
> ++
> | EXPR$0 |
> ++
> Query failed: RemoteRpcException: Failure while running fragment., Failure
> while reading vector. Expected vector class of
> org.apache.drill.exec.vector.IntVector but was holding vector class
> org.apache.drill.exec.vector.NullableIntVector. [
> 5610e589-38e0-4dc5-a560-649516180ba4 on atsqa4-134.qa.lab:31010 ]
> [ 5610e589-38e0-4dc5-a560-649516180ba4 on atsqa4-134.qa.lab:31010 ]
> java.lang.RuntimeException: java.sql.SQLException: Failure while executing
> query.
> at sqlline.SqlLine$
[jira] [Commented] (DRILL-2906) CTAS with store.format = 'json' returns incorrect results
[ https://issues.apache.org/jira/browse/DRILL-2906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14529273#comment-14529273 ] Steven Phillips commented on DRILL-2906: Does this only occur when selecting a literal value? Or does it happen in other cases, too? > CTAS with store.format = 'json' returns incorrect results > - > > Key: DRILL-2906 > URL: https://issues.apache.org/jira/browse/DRILL-2906 > Project: Apache Drill > Issue Type: Bug > Components: Storage - JSON, Storage - Writer >Reporter: Mehant Baid >Assignee: Steven Phillips > Fix For: 1.0.0 > > > Performing a CTAS with 'store.format' = 'json' and querying the table results > in projecting an addition field '*' will null values. Below is a simple repro > 0: jdbc:drill:zk=local> create table t as select timestamp '1980-10-01 > 00:00:00' from cp.`employee.json` limit 1; > ++---+ > | Fragment | Number of records written | > ++---+ > | 0_0| 1 | > ++---+ > 1 row selected (0.314 seconds) > 0: jdbc:drill:zk=local> select * from t; > +++ > | EXPR$0 | * | > +++ > | 1980-10-01 00:00:00.0 | null | > +++ > Notice in the above result set we get an extra column '*' with null value. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-625) Server does not release resources even after client connection is closed
[ https://issues.apache.org/jira/browse/DRILL-625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steven Phillips updated DRILL-625: -- Assignee: Parth Chandra (was: Steven Phillips) > Server does not release resources even after client connection is closed > > > Key: DRILL-625 > URL: https://issues.apache.org/jira/browse/DRILL-625 > Project: Apache Drill > Issue Type: Bug > Components: Execution - RPC >Affects Versions: m1 >Reporter: Parth Chandra >Assignee: Parth Chandra >Priority: Critical > Fix For: 1.0.0 > > > This problem occurred with the C++ client. The client was not sending a final > ack and instead closed the connection. The server does not close the channel > even though the socket connection has been closed and backs up eventually > appearing to hang. > The client has been fixed but the server should release the resources as the > client connection can break during a session due to any number of other > reasons. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (DRILL-2964) Extended Json : Repeated date and time columns reporting wrong values
Rahul Challapalli created DRILL-2964:
Summary: Extended Json : Repeated date and time columns reporting
wrong values
Key: DRILL-2964
URL: https://issues.apache.org/jira/browse/DRILL-2964
Project: Apache Drill
Issue Type: Bug
Components: Storage - JSON
Reporter: Rahul Challapalli
Assignee: Steven Phillips
Priority: Critical
git.commit.id.abbrev=f240ac2
Data :
{code}
{
"int_col" : {"$numberLong": 1},
"date_col" : {"$dateDay": "2012-05-22"},
"time_col" : {"$time": "19:20:30.45Z"},
"date_array" : [{"$dateDay" : "2012-08-01"}, {"$dateDay" : "2033-11-28"}],
"time_array" : [{"$time": "19:20:30.45Z"}, {"$time": "11:25:01.45Z"}],
"int_array" : [{"$numberLong": 1}, {"$numberLong": 2}, {"$numberLong": 3}]
}
{code}
Query :
{code}
0: jdbc:drill:schema=dfs_eea> select time_array, date_array from `data1.json`;
+++
| time_array | date_array |
+++
|
[{"dayOfMonth":1,"dayOfWeek":4,"era":1,"year":1970,"dayOfYear":1,"centuryOfEra":19,"millisOfSecond":450,"millisOfDay":69630450,"secondOfMinute":30,"secondOfDay":69630,"minuteOfHour":20,"minuteOfDay":1160,"hourOfDay":19,"weekOfWeekyear":1,"weekyear":1970,"monthOfYear":1,"yearOfEra":1970,"yearOfCentury":70,"zone":{"fixed":true,"id":"UTC"},"millis":69630450,"chronology":{"zone":{"fixed":true,"id":"UTC"}},"afterNow":false,"equalNow":false,"beforeNow":true},{"dayOfMonth":1,"dayOfWeek":4,"era":1,"year":1970,"dayOfYear":1,"centuryOfEra":19,"millisOfSecond":450,"millisOfDay":41101450,"secondOfMinute":1,"secondOfDay":41101,"minuteOfHour":25,"minuteOfDay":685,"hourOfDay":11,"weekOfWeekyear":1,"weekyear":1970,"monthOfYear":1,"yearOfEra":1970,"yearOfCentury":70,"zone":{"fixed":true,"id":"UTC"},"millis":41101450,"chronology":{"zone":{"fixed":true,"id":"UTC"}},"afterNow":false,"equalNow":false,"beforeNow":true}]
|
[{"dayOfMonth":1,"dayOfWeek":3,"era":1,"year":2012,"dayOfYear":214,"centuryOfEra":20,"millisOfSecond":0,"millisOfDay":0,"secondOfMinute":0,"secondOfDay":0,"minuteOfHour":0,"minuteOfDay":0,"hourOfDay":0,"weekOfWeekyear":31,"weekyear":2012,"monthOfYear":8,"yearOfEra":2012,"yearOfCentury":12,"zone":{"fixed":true,"id":"UTC"},"millis":134377920,"chronology":{"zone":{"fixed":true,"id":"UTC"}},"afterNow":false,"equalNow":false,"beforeNow":true},{"dayOfMonth":28,"dayOfWeek":1,"era":1,"year":2033,"dayOfYear":332,"centuryOfEra":20,"millisOfSecond":0,"millisOfDay":0,"secondOfMinute":0,"secondOfDay":0,"minuteOfHour":0,"minuteOfDay":0,"hourOfDay":0,"weekOfWeekyear":48,"weekyear":2033,"monthOfYear":11,"yearOfEra":2033,"yearOfCentury":33,"zone":{"fixed":true,"id":"UTC"},"millis":201674880,"chronology":{"zone":{"fixed":true,"id":"UTC"}},"afterNow":true,"equalNow":false,"beforeNow":false}]
|
{code}
Drill could be serializing the whole date object here. Marked it as critical
since we are reporting wrong data. Let me know if you have any questions.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (DRILL-2963) Exists with empty left batch causes IllegalStateException
Mehant Baid created DRILL-2963: -- Summary: Exists with empty left batch causes IllegalStateException Key: DRILL-2963 URL: https://issues.apache.org/jira/browse/DRILL-2963 Project: Apache Drill Issue Type: Bug Reporter: Mehant Baid Assignee: Mehant Baid Fix For: 1.0.0 In NestedLoopJoinBatch we don't correctly handle the case when we have an empty left input batch, need to return NONE in that case. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (DRILL-2962) Correlates subquery with scalar aggregate or scalar aggregate with expression throws and error
Victoria Markman created DRILL-2962:
---
Summary: Correlates subquery with scalar aggregate or scalar
aggregate with expression throws and error
Key: DRILL-2962
URL: https://issues.apache.org/jira/browse/DRILL-2962
Project: Apache Drill
Issue Type: Bug
Components: Query Planning & Optimization
Affects Versions: 0.9.0
Reporter: Victoria Markman
Assignee: Aman Sinha
Priority: Critical
Fix For: 1.0.0
Filing this bug on Aman's request. It is not the same as DRILL-2949
DRILL-2949 has two outer tables.
{code}
0: jdbc:drill:schema=dfs> select * from t1 where a1 > (select avg(a2)*100 from
t2 where c1 = c2);
Query failed: SYSTEM ERROR: Non-scalar sub-query used in an expression
See Apache Drill JIRA: DRILL-1937
[991f5544-d44f-4ba2-aa70-783a88a5b16a on atsqa4-133.qa.lab:31010]
Error: exception while executing query: Failure while executing query.
(state=,code=0)
Correlated scalar aggregation without expression:
0: jdbc:drill:schema=dfs> select * from t1 where a1 > (select avg(a2) from t2
where c1 = c2);
Query failed: SYSTEM ERROR: This query cannot be planned possibly due to either
a cartesian join or an inequality join
[f238c0c0-efea-4684-8ec3-899fbcc2a075 on atsqa4-133.qa.lab:31010]
Error: exception while executing query: Failure while executing query.
(state=,code=0)
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DRILL-2229) SQL syntax errors should use SQLSyntaxErrorException
[ https://issues.apache.org/jira/browse/DRILL-2229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14529082#comment-14529082 ] Daniel Barclay (Drill) commented on DRILL-2229: --- > Did you mean the exception which would be thrown when optiq parses input SQL > string (which is SqlParseException)? I did (when I submitted that), but now with our change to UserException, this changes to "SQL syntax error should use UserException and its PARSE ERROR error type." I don't know how much that has already been applied. (If the answer is "mostly," then this JIRA report can probably be closed. If the answer is just "somewhat," then maybe this JIRA should be retitled (to refer to PARSE ERROR).) > SQL syntax errors should use SQLSyntaxErrorException > > > Key: DRILL-2229 > URL: https://issues.apache.org/jira/browse/DRILL-2229 > Project: Apache Drill > Issue Type: Bug > Components: SQL Parser >Reporter: Daniel Barclay (Drill) >Assignee: Sean Hsuan-Yi Chu > Fix For: 1.2.0 > > > SQL syntax errors should be reported with SQLSyntaxErrorException (or > subclasses, of course) rather than SQLException (in part so that when they > get to the JDBC interface they can be reported at intended using > SQLSyntaxErrorException . -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DRILL-2757) Verify operators correctly handle low memory conditions and cancellations
[
https://issues.apache.org/jira/browse/DRILL-2757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14529072#comment-14529072
]
Deneche A. Hakim commented on DRILL-2757:
-
Oops, forgot to link it here.
Review request [33829|https://reviews.apache.org/r/33829/]
> Verify operators correctly handle low memory conditions and cancellations
> -
>
> Key: DRILL-2757
> URL: https://issues.apache.org/jira/browse/DRILL-2757
> Project: Apache Drill
> Issue Type: Bug
> Components: Execution - Flow, Execution - Relational Operators
>Affects Versions: 0.8.0
>Reporter: Chris Westin
>Assignee: Steven Phillips
> Fix For: 1.0.0
>
> Attachments: DRILL-2757.1.patch.txt
>
>
> Check that the path through sort that notices low memory conditions and
> causes the sort to spill ("out of memory condition management").
> Also check to make sure we handle queries and fragment failures properly
> under these conditions.
> "hashjoin, hashagg, and topn use large amounts of memory,and may be unable to
> complete if their memory needs can't be met; for all others, the idea is that
> they can complete if they get their reservation"
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DRILL-2757) Verify operators correctly handle low memory conditions and cancellations
[
https://issues.apache.org/jira/browse/DRILL-2757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14529062#comment-14529062
]
Steven Phillips commented on DRILL-2757:
Could you please create a ReviewBoard, since this is moderately sized patch.
> Verify operators correctly handle low memory conditions and cancellations
> -
>
> Key: DRILL-2757
> URL: https://issues.apache.org/jira/browse/DRILL-2757
> Project: Apache Drill
> Issue Type: Bug
> Components: Execution - Flow, Execution - Relational Operators
>Affects Versions: 0.8.0
>Reporter: Chris Westin
>Assignee: Steven Phillips
> Fix For: 1.0.0
>
> Attachments: DRILL-2757.1.patch.txt
>
>
> Check that the path through sort that notices low memory conditions and
> causes the sort to spill ("out of memory condition management").
> Also check to make sure we handle queries and fragment failures properly
> under these conditions.
> "hashjoin, hashagg, and topn use large amounts of memory,and may be unable to
> complete if their memory needs can't be met; for all others, the idea is that
> they can complete if they get their reservation"
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (DRILL-2167) Order by on a repeated index from the output of a flatten on large no of records results in incorrect results
[
https://issues.apache.org/jira/browse/DRILL-2167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Altekruse reassigned DRILL-2167:
--
Assignee: Jason Altekruse (was: Sudheesh Katkam)
> Order by on a repeated index from the output of a flatten on large no of
> records results in incorrect results
> -
>
> Key: DRILL-2167
> URL: https://issues.apache.org/jira/browse/DRILL-2167
> Project: Apache Drill
> Issue Type: Bug
> Components: Execution - Relational Operators
>Reporter: Rahul Challapalli
>Assignee: Jason Altekruse
>Priority: Critical
> Fix For: 1.0.0
>
> Attachments: data.json
>
>
> git.commit.id.abbrev=3e33880
> The below query results in 26 records. Based on the data set we should
> only receive 20 records.
> {code}
> select s.uid from (select d.uid, flatten(d.map.rm) rms from `data.json` d) s
> order by s.rms.rptd[1].d;
> {code}
> When I removed the order by part, drill correctly reported 20 records.
> {code}
> select s.uid from (select d.uid, flatten(d.map.rm) rms from `data.json` d) s;
> {code}
> I attached the data set with 2 records. I copied over the data set 5
> times and ran the queries on top of it. Let me know if you have any other
> questions
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DRILL-2482) JDBC : calling getObject when the actual column type is 'NVARCHAR' results in NoClassDefFoundError
[
https://issues.apache.org/jira/browse/DRILL-2482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14529047#comment-14529047
]
Daniel Barclay (Drill) commented on DRILL-2482:
---
Note: This report is likely obsolete now because the bug that cause VARCHAR to
show up as NVARCHAR has been fixed.
> JDBC : calling getObject when the actual column type is 'NVARCHAR' results in
> NoClassDefFoundError
> --
>
> Key: DRILL-2482
> URL: https://issues.apache.org/jira/browse/DRILL-2482
> Project: Apache Drill
> Issue Type: Bug
> Components: Client - JDBC
>Reporter: Rahul Challapalli
>Assignee: Rahul Challapalli
> Fix For: 1.2.0
>
>
> git.commit.id.abbrev=7b4c887
> I tried to call getObject(i) on a column which is of type varchar, drill
> failed with the below error :
> {code}
> Exception in thread "main" java.lang.NoClassDefFoundError:
> org/apache/hadoop/io/Text
> at
> org.apache.drill.exec.vector.VarCharVector$Accessor.getObject(VarCharVector.java:407)
> at
> org.apache.drill.exec.vector.NullableVarCharVector$Accessor.getObject(NullableVarCharVector.java:386)
> at
> org.apache.drill.exec.vector.accessor.NullableVarCharAccessor.getObject(NullableVarCharAccessor.java:98)
> at
> org.apache.drill.exec.vector.accessor.BoundCheckingAccessor.getObject(BoundCheckingAccessor.java:137)
> at
> org.apache.drill.jdbc.AvaticaDrillSqlAccessor.getObject(AvaticaDrillSqlAccessor.java:136)
> at
> net.hydromatic.avatica.AvaticaResultSet.getObject(AvaticaResultSet.java:351)
> at Dummy.testComplexQuery(Dummy.java:94)
> at Dummy.main(Dummy.java:30)
> Caused by: java.lang.ClassNotFoundException: org.apache.hadoop.io.Text
> at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
> ... 8 more
> {code}
> When the underlying type is a primitive, the getObject call succeeds
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DRILL-2936) TPCH 4 and 18 SF100 hangs when hash agg is turned off
[
https://issues.apache.org/jira/browse/DRILL-2936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14529048#comment-14529048
]
Steven Phillips commented on DRILL-2936:
Did you also check drillbit.out on each node?
> TPCH 4 and 18 SF100 hangs when hash agg is turned off
> -
>
> Key: DRILL-2936
> URL: https://issues.apache.org/jira/browse/DRILL-2936
> Project: Apache Drill
> Issue Type: Bug
> Components: Execution - Flow
>Reporter: Ramana Inukonda Nagaraj
>Assignee: Steven Phillips
>Priority: Critical
> Fix For: 1.0.0
>
> Attachments: Screen Shot 2015-05-01 at 2.40.36 PM.png
>
>
> sys options:
> {code}
> 0: jdbc:drill:schema=dfs.drillTestDirTpch100P> alter system set
> `planner.memory.max_query_memory_per_node` = 29205777612;
> 0: jdbc:drill:schema=dfs.drillTestDirTpch100P> alter system set
> `planner.enable_hashjoin`=false;
> 0: jdbc:drill:schema=dfs.drillTestDirTpch100P> alter system set
> `planner.enable_hashagg`=false;
> {code}
> On executing TPCH 04 query hangs. From the profiles page does not look like
> any fragments are making progress, the last progress time stamps were
> sometime back.
> Attached is the logical plan.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DRILL-2535) Column labels on drill profile page are incorrect
[ https://issues.apache.org/jira/browse/DRILL-2535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudheesh Katkam updated DRILL-2535: --- Assignee: Jason Altekruse (was: Sudheesh Katkam) > Column labels on drill profile page are incorrect > - > > Key: DRILL-2535 > URL: https://issues.apache.org/jira/browse/DRILL-2535 > Project: Apache Drill > Issue Type: Bug > Components: Client - HTTP >Affects Versions: 0.9.0 >Reporter: Krystal >Assignee: Jason Altekruse > Fix For: 1.2.0 > > Attachments: DRILL-2535.1.patch.txt > > > git.commit.id=4d398edf87d2ec6fab6c552b1f5a33fb31b955bc > The section where it breaks down data per majorId/operatorId/operatorType as > shown below in the UI Query and Planning page contains mis-leading column > headers. These column names are Max Batches, Max Records and Peak Mem. The > values displayed here are just listing of records from the profile json; > there were no aggregations performed. Therefore, the column name should be > just "Batches", "Records", and "Memory" > 02-xx-03 - HASH_AGGREGATE > Minor FragmentSetup Process WaitMax Batches Max Records > Peak Mem > 02-00-03 0.312 0.192 0.000 80 80,195 4MB > 02-01-03 0.310 0.188 0.000 80 79,797 4MB > 02-02-03 0.312 0.192 0.000 80 80,008 4MB -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-2569) Minor fragmentId in Profile UI gets truncated to the last 2 digits
[ https://issues.apache.org/jira/browse/DRILL-2569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudheesh Katkam updated DRILL-2569: --- Assignee: Jason Altekruse (was: Sudheesh Katkam) > Minor fragmentId in Profile UI gets truncated to the last 2 digits > -- > > Key: DRILL-2569 > URL: https://issues.apache.org/jira/browse/DRILL-2569 > Project: Apache Drill > Issue Type: Bug > Components: Client - HTTP >Affects Versions: 0.9.0 >Reporter: Krystal >Assignee: Jason Altekruse > Fix For: 1.2.0 > > Attachments: DRILL-2569.1.patch.txt > > > git.commit.id.abbrev=8493713 > When the profile json contains minorFragmentId > 99, the UI only display the > last 2 digits. For example if minorFragmentId=100, it is being displayed as > "00". Here is a snippet of such data from the profile UI: > 04-xx-03 - PARQUET_ROW_GROUP_SCAN > Minor FragmentSetup Process WaitMax Batches Max Records > Peak Mem > 04-98-03 0.000 3.807 1.795 0 0 15MB > 04-99-03 0.000 3.247 3.111 0 0 24MB > 04-00-03 0.000 3.163 2.545 0 0 20MB > 04-01-03 0.000 3.272 2.278 0 0 15MB > 04-02-03 0.000 3.496 2.004 0 0 15MB -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-2536) Peak Mem column in the profile page displays 0 when value is less than 1MB
[ https://issues.apache.org/jira/browse/DRILL-2536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudheesh Katkam updated DRILL-2536: --- Assignee: Jason Altekruse (was: Sudheesh Katkam) > Peak Mem column in the profile page displays 0 when value is less than 1MB > -- > > Key: DRILL-2536 > URL: https://issues.apache.org/jira/browse/DRILL-2536 > Project: Apache Drill > Issue Type: Bug > Components: Client - HTTP >Affects Versions: 0.9.0 >Reporter: Krystal >Assignee: Jason Altekruse > Fix For: 1.2.0 > > Attachments: DRILL-2536.1.patch.txt > > > git.commit.id=4d398edf87d2ec6fab6c552b1f5a33fb31b955bc > For the "Peak Mem" column in the Query and Planning page, the value is > displayed as 0 when the actual value is less than 1MB. We should display > more granular value for this especially for smaller jobs; maybe display up to > 2 or 3 digits after the decimal. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-2772) Display status of query when viewing the query's profile page
[ https://issues.apache.org/jira/browse/DRILL-2772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudheesh Katkam updated DRILL-2772: --- Assignee: Jason Altekruse (was: Sudheesh Katkam) > Display status of query when viewing the query's profile page > - > > Key: DRILL-2772 > URL: https://issues.apache.org/jira/browse/DRILL-2772 > Project: Apache Drill > Issue Type: Improvement > Components: Client - HTTP >Affects Versions: 0.8.0 > Environment: RHEL 6.4 >Reporter: Kunal Khatua >Assignee: Jason Altekruse > Fix For: 1.2.0 > > Attachments: DRILL-2772.1.patch.txt > > > When viewing the profile of a query that has run/executed a while ago, it > would be helpful to see whether the query was marked as completed, cancelled > or failed. > The summary on the http://:8047/profiles page shows the status but > none of the profile pages show this information. Since the summary is limited > to the last 100 queries, having the status would help. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-2536) Peak Mem column in the profile page displays 0 when value is less than 1MB
[ https://issues.apache.org/jira/browse/DRILL-2536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudheesh Katkam updated DRILL-2536: --- Attachment: DRILL-2536.1.patch.txt > Peak Mem column in the profile page displays 0 when value is less than 1MB > -- > > Key: DRILL-2536 > URL: https://issues.apache.org/jira/browse/DRILL-2536 > Project: Apache Drill > Issue Type: Bug > Components: Client - HTTP >Affects Versions: 0.9.0 >Reporter: Krystal >Assignee: Sudheesh Katkam > Fix For: 1.2.0 > > Attachments: DRILL-2536.1.patch.txt > > > git.commit.id=4d398edf87d2ec6fab6c552b1f5a33fb31b955bc > For the "Peak Mem" column in the Query and Planning page, the value is > displayed as 0 when the actual value is less than 1MB. We should display > more granular value for this especially for smaller jobs; maybe display up to > 2 or 3 digits after the decimal. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-2569) Minor fragmentId in Profile UI gets truncated to the last 2 digits
[ https://issues.apache.org/jira/browse/DRILL-2569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudheesh Katkam updated DRILL-2569: --- Attachment: DRILL-2569.1.patch.txt > Minor fragmentId in Profile UI gets truncated to the last 2 digits > -- > > Key: DRILL-2569 > URL: https://issues.apache.org/jira/browse/DRILL-2569 > Project: Apache Drill > Issue Type: Bug > Components: Client - HTTP >Affects Versions: 0.9.0 >Reporter: Krystal >Assignee: Sudheesh Katkam > Fix For: 1.2.0 > > Attachments: DRILL-2569.1.patch.txt > > > git.commit.id.abbrev=8493713 > When the profile json contains minorFragmentId > 99, the UI only display the > last 2 digits. For example if minorFragmentId=100, it is being displayed as > "00". Here is a snippet of such data from the profile UI: > 04-xx-03 - PARQUET_ROW_GROUP_SCAN > Minor FragmentSetup Process WaitMax Batches Max Records > Peak Mem > 04-98-03 0.000 3.807 1.795 0 0 15MB > 04-99-03 0.000 3.247 3.111 0 0 24MB > 04-00-03 0.000 3.163 2.545 0 0 20MB > 04-01-03 0.000 3.272 2.278 0 0 15MB > 04-02-03 0.000 3.496 2.004 0 0 15MB -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-2772) Display status of query when viewing the query's profile page
[ https://issues.apache.org/jira/browse/DRILL-2772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudheesh Katkam updated DRILL-2772: --- Attachment: DRILL-2772.1.patch.txt > Display status of query when viewing the query's profile page > - > > Key: DRILL-2772 > URL: https://issues.apache.org/jira/browse/DRILL-2772 > Project: Apache Drill > Issue Type: Improvement > Components: Client - HTTP >Affects Versions: 0.8.0 > Environment: RHEL 6.4 >Reporter: Kunal Khatua >Assignee: Sudheesh Katkam > Fix For: 1.2.0 > > Attachments: DRILL-2772.1.patch.txt > > > When viewing the profile of a query that has run/executed a while ago, it > would be helpful to see whether the query was marked as completed, cancelled > or failed. > The summary on the http://:8047/profiles page shows the status but > none of the profile pages show this information. Since the summary is limited > to the last 100 queries, having the status would help. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-2535) Column labels on drill profile page are incorrect
[ https://issues.apache.org/jira/browse/DRILL-2535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudheesh Katkam updated DRILL-2535: --- Attachment: DRILL-2535.1.patch.txt > Column labels on drill profile page are incorrect > - > > Key: DRILL-2535 > URL: https://issues.apache.org/jira/browse/DRILL-2535 > Project: Apache Drill > Issue Type: Bug > Components: Client - HTTP >Affects Versions: 0.9.0 >Reporter: Krystal >Assignee: Sudheesh Katkam > Fix For: 1.2.0 > > Attachments: DRILL-2535.1.patch.txt > > > git.commit.id=4d398edf87d2ec6fab6c552b1f5a33fb31b955bc > The section where it breaks down data per majorId/operatorId/operatorType as > shown below in the UI Query and Planning page contains mis-leading column > headers. These column names are Max Batches, Max Records and Peak Mem. The > values displayed here are just listing of records from the profile json; > there were no aggregations performed. Therefore, the column name should be > just "Batches", "Records", and "Memory" > 02-xx-03 - HASH_AGGREGATE > Minor FragmentSetup Process WaitMax Batches Max Records > Peak Mem > 02-00-03 0.312 0.192 0.000 80 80,195 4MB > 02-01-03 0.310 0.188 0.000 80 79,797 4MB > 02-02-03 0.312 0.192 0.000 80 80,008 4MB -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-2691) Source files with Windows line endings
[
https://issues.apache.org/jira/browse/DRILL-2691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Westin updated DRILL-2691:
Assignee: Jason Altekruse (was: Venki Korukanti)
> Source files with Windows line endings
> --
>
> Key: DRILL-2691
> URL: https://issues.apache.org/jira/browse/DRILL-2691
> Project: Apache Drill
> Issue Type: Bug
> Components: Tools, Build & Test
>Affects Versions: 0.6.0
>Reporter: Deneche A. Hakim
>Assignee: Jason Altekruse
> Fix For: 1.0.0
>
> Attachments: DRILL-2691.1.patch.txt
>
>
> The following files:
> {noformat}
> common/src/main/java/org/apache/drill/common/util/DrillStringUtils.java
> contrib/storage-hbase/src/test/java/org/apache/drill/hbase/TestHBaseCFAsJSONString.java
> {noformat}
> Have Windows line endings in them. Trying to apply a patch that contains
> changes in one of those files will fail.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DRILL-2516) CTAS fails with NPE when select statement contains join and columns are not specified explicitly
[
https://issues.apache.org/jira/browse/DRILL-2516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14529012#comment-14529012
]
Chris Westin commented on DRILL-2516:
-
[~vkorukanti] says "doesn't repro on latest master. I remember trying with
assert enabled, but lets run then once again with asserts enabled to make sure
it is not reporing. If not reproing, mostly likely fixed by Jinfeng's Calcite
rebase fixes. Check with him to figure out which one fixed the issue"
[~jaltekruse], can you please verify?
> CTAS fails with NPE when select statement contains join and columns are not
> specified explicitly
>
>
> Key: DRILL-2516
> URL: https://issues.apache.org/jira/browse/DRILL-2516
> Project: Apache Drill
> Issue Type: Bug
> Components: Execution - Relational Operators
>Affects Versions: 0.8.0
>Reporter: Victoria Markman
>Assignee: Venki Korukanti
> Fix For: 1.0.0
>
> Attachments: t1.parquet, t2.parquet
>
>
> {code}
> 0: jdbc:drill:schema=dfs> select * from t1, t2 where t1.a1 = t2.a2;
> +++++++
> | a1 | b1 | c1 | a2 | b2 | c2
> |
> +++++++
> | 1 | a | 2015-01-01 | 1 | a | 2015-01-01
> |
> | 2 | b | 2015-01-02 | 2 | b | 2015-01-02
> |
> | 2 | b | 2015-01-02 | 2 | b | 2015-01-02
> |
> | 2 | b | 2015-01-02 | 2 | b | 2015-01-02
> |
> | 3 | c | 2015-01-03 | 3 | c | 2015-01-03
> |
> | 4 | null | 2015-01-04 | 4 | d | 2015-01-04
> |
> | 5 | e | 2015-01-05 | 5 | e | 2015-01-05
> |
> | 6 | f | 2015-01-06 | 6 | f | 2015-01-06
> |
> | 7 | g | 2015-01-07 | 7 | g | 2015-01-07
> |
> | 7 | g | 2015-01-07 | 7 | g | 2015-01-07
> |
> | 9 | i | null | 9 | i | 2015-01-09
> |
> +++++++
> 11 rows selected (0.253 seconds)
> {code}
> CTAS assert:
> {code}
> 0: jdbc:drill:schema=dfs> create table test as select * from t1, t2 where
> t1.a1 = t2.a2;
> Query failed: RemoteRpcException: Failure while running fragment.[
> 83a1a356-b427-4dce-822f-6ae35ef9ca38 on atsqa4-134.qa.lab:31010 ]
> [ 83a1a356-b427-4dce-822f-6ae35ef9ca38 on atsqa4-134.qa.lab:31010 ]
> Error: exception while executing query: Failure while executing query.
> (state=,code=0)
> {code}
> From drillbit.log
> {code}
> 2015-03-20 23:40:30,017 [2af35011-91c9-7834-14b3-863cb0cf41d2:frag:0:0] ERROR
> o.a.d.e.w.f.AbstractStatusReporter - Error
> 83a1a356-b427-4dce-822f-6ae35ef9ca38: Failure while running fragment.
> java.lang.AssertionError: null
> at
> org.apache.drill.exec.physical.impl.project.ProjectRecordBatch.setupNewSchema(ProjectRecordBatch.java:347)
> ~[drill-java-exec-0.8.0-SNAPSHOT-rebuffed.jar:0.8.0-SNAPSHOT]
> at
> org.apache.drill.exec.record.AbstractSingleRecordBatch.innerNext(AbstractSingleRecordBatch.java:78)
> ~[drill-java-exec-0.8.0-SNAPSHOT-rebuffed.jar:0.8.0-SNAPSHOT]
> at
> org.apache.drill.exec.physical.impl.project.ProjectRecordBatch.innerNext(ProjectRecordBatch.java:134)
> ~[drill-java-exec-0.8.0-SNAPSHOT-rebuffed.jar:0.8.0-SNAPSHOT]
> at
> org.apache.drill.exec.record.AbstractRecordBatch.next(AbstractRecordBatch.java:142)
> ~[drill-java-exec-0.8.0-SNAPSHOT-rebuffed.jar:0.8.0-SNAPSHOT]
> at
> org.apache.drill.exec.physical.impl.validate.IteratorValidatorBatchIterator.next(IteratorValidatorBatchIterator.java:118)
> ~[drill-java-exec-0.8.0-SNAPSHOT-rebuffed.jar:0.8.0-SNAPSHOT]
> at
> org.apache.drill.exec.record.AbstractRecordBatch.next(AbstractRecordBatch.java:99)
> ~[drill-java-exec-0.8.0-SNAPSHOT-rebuffed.jar:0.8.0-SNAPSHOT]
> at
> org.apache.drill.exec.record.AbstractRecordBatch.next(AbstractRecordBatch.java:89)
> ~[drill-java-exec-0.8.0-SNAPSHOT-rebuffed.jar:0.8.0-SNAPSHOT]
> at
> org.apache.drill.exec.physical.impl.WriterRecordBatch.innerNext(WriterRecordBatch.java:102)
> ~[drill-java-exec-0.8.0-SNAPSHOT-rebuffed.jar:0.8.0-SNAPSHOT]
> at
> org.apache.drill.exec.record.AbstractRecordBatch.next(AbstractRecordBatch.java:142)
> ~[drill-java-exec-0.8.0-SNAPSHOT-rebuffed.jar:0.8.0-SNAPSHOT]
> at
> org.apache.drill.exec.physical.impl.validate.IteratorValidatorBatchIterator.next(IteratorValidatorBatchIt
[jira] [Updated] (DRILL-2516) CTAS fails with NPE when select statement contains join and columns are not specified explicitly
[
https://issues.apache.org/jira/browse/DRILL-2516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Westin updated DRILL-2516:
Assignee: Jason Altekruse (was: Venki Korukanti)
> CTAS fails with NPE when select statement contains join and columns are not
> specified explicitly
>
>
> Key: DRILL-2516
> URL: https://issues.apache.org/jira/browse/DRILL-2516
> Project: Apache Drill
> Issue Type: Bug
> Components: Execution - Relational Operators
>Affects Versions: 0.8.0
>Reporter: Victoria Markman
>Assignee: Jason Altekruse
> Fix For: 1.0.0
>
> Attachments: t1.parquet, t2.parquet
>
>
> {code}
> 0: jdbc:drill:schema=dfs> select * from t1, t2 where t1.a1 = t2.a2;
> +++++++
> | a1 | b1 | c1 | a2 | b2 | c2
> |
> +++++++
> | 1 | a | 2015-01-01 | 1 | a | 2015-01-01
> |
> | 2 | b | 2015-01-02 | 2 | b | 2015-01-02
> |
> | 2 | b | 2015-01-02 | 2 | b | 2015-01-02
> |
> | 2 | b | 2015-01-02 | 2 | b | 2015-01-02
> |
> | 3 | c | 2015-01-03 | 3 | c | 2015-01-03
> |
> | 4 | null | 2015-01-04 | 4 | d | 2015-01-04
> |
> | 5 | e | 2015-01-05 | 5 | e | 2015-01-05
> |
> | 6 | f | 2015-01-06 | 6 | f | 2015-01-06
> |
> | 7 | g | 2015-01-07 | 7 | g | 2015-01-07
> |
> | 7 | g | 2015-01-07 | 7 | g | 2015-01-07
> |
> | 9 | i | null | 9 | i | 2015-01-09
> |
> +++++++
> 11 rows selected (0.253 seconds)
> {code}
> CTAS assert:
> {code}
> 0: jdbc:drill:schema=dfs> create table test as select * from t1, t2 where
> t1.a1 = t2.a2;
> Query failed: RemoteRpcException: Failure while running fragment.[
> 83a1a356-b427-4dce-822f-6ae35ef9ca38 on atsqa4-134.qa.lab:31010 ]
> [ 83a1a356-b427-4dce-822f-6ae35ef9ca38 on atsqa4-134.qa.lab:31010 ]
> Error: exception while executing query: Failure while executing query.
> (state=,code=0)
> {code}
> From drillbit.log
> {code}
> 2015-03-20 23:40:30,017 [2af35011-91c9-7834-14b3-863cb0cf41d2:frag:0:0] ERROR
> o.a.d.e.w.f.AbstractStatusReporter - Error
> 83a1a356-b427-4dce-822f-6ae35ef9ca38: Failure while running fragment.
> java.lang.AssertionError: null
> at
> org.apache.drill.exec.physical.impl.project.ProjectRecordBatch.setupNewSchema(ProjectRecordBatch.java:347)
> ~[drill-java-exec-0.8.0-SNAPSHOT-rebuffed.jar:0.8.0-SNAPSHOT]
> at
> org.apache.drill.exec.record.AbstractSingleRecordBatch.innerNext(AbstractSingleRecordBatch.java:78)
> ~[drill-java-exec-0.8.0-SNAPSHOT-rebuffed.jar:0.8.0-SNAPSHOT]
> at
> org.apache.drill.exec.physical.impl.project.ProjectRecordBatch.innerNext(ProjectRecordBatch.java:134)
> ~[drill-java-exec-0.8.0-SNAPSHOT-rebuffed.jar:0.8.0-SNAPSHOT]
> at
> org.apache.drill.exec.record.AbstractRecordBatch.next(AbstractRecordBatch.java:142)
> ~[drill-java-exec-0.8.0-SNAPSHOT-rebuffed.jar:0.8.0-SNAPSHOT]
> at
> org.apache.drill.exec.physical.impl.validate.IteratorValidatorBatchIterator.next(IteratorValidatorBatchIterator.java:118)
> ~[drill-java-exec-0.8.0-SNAPSHOT-rebuffed.jar:0.8.0-SNAPSHOT]
> at
> org.apache.drill.exec.record.AbstractRecordBatch.next(AbstractRecordBatch.java:99)
> ~[drill-java-exec-0.8.0-SNAPSHOT-rebuffed.jar:0.8.0-SNAPSHOT]
> at
> org.apache.drill.exec.record.AbstractRecordBatch.next(AbstractRecordBatch.java:89)
> ~[drill-java-exec-0.8.0-SNAPSHOT-rebuffed.jar:0.8.0-SNAPSHOT]
> at
> org.apache.drill.exec.physical.impl.WriterRecordBatch.innerNext(WriterRecordBatch.java:102)
> ~[drill-java-exec-0.8.0-SNAPSHOT-rebuffed.jar:0.8.0-SNAPSHOT]
> at
> org.apache.drill.exec.record.AbstractRecordBatch.next(AbstractRecordBatch.java:142)
> ~[drill-java-exec-0.8.0-SNAPSHOT-rebuffed.jar:0.8.0-SNAPSHOT]
> at
> org.apache.drill.exec.physical.impl.validate.IteratorValidatorBatchIterator.next(IteratorValidatorBatchIterator.java:118)
> ~[drill-java-exec-0.8.0-SNAPSHOT-rebuffed.jar:0.8.0-SNAPSHOT]
> at
> org.apache.drill.exec.record.AbstractRecordBatch.next(AbstractRecordBatch.java:99)
> ~[drill-java-exec-0.8.0-SNAPSHOT-rebuffed.jar:0.8.0-SNAPSHOT]
> at
> org.apache.drill.exec.record.AbstractRecordBatch.next(AbstractRecordBatch.java:89)
> ~
[jira] [Updated] (DRILL-2516) CTAS fails with NPE when select statement contains join and columns are not specified explicitly
[
https://issues.apache.org/jira/browse/DRILL-2516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Westin updated DRILL-2516:
Component/s: (was: Storage - Writer)
Execution - Relational Operators
> CTAS fails with NPE when select statement contains join and columns are not
> specified explicitly
>
>
> Key: DRILL-2516
> URL: https://issues.apache.org/jira/browse/DRILL-2516
> Project: Apache Drill
> Issue Type: Bug
> Components: Execution - Relational Operators
>Affects Versions: 0.8.0
>Reporter: Victoria Markman
>Assignee: Venki Korukanti
> Fix For: 1.0.0
>
> Attachments: t1.parquet, t2.parquet
>
>
> {code}
> 0: jdbc:drill:schema=dfs> select * from t1, t2 where t1.a1 = t2.a2;
> +++++++
> | a1 | b1 | c1 | a2 | b2 | c2
> |
> +++++++
> | 1 | a | 2015-01-01 | 1 | a | 2015-01-01
> |
> | 2 | b | 2015-01-02 | 2 | b | 2015-01-02
> |
> | 2 | b | 2015-01-02 | 2 | b | 2015-01-02
> |
> | 2 | b | 2015-01-02 | 2 | b | 2015-01-02
> |
> | 3 | c | 2015-01-03 | 3 | c | 2015-01-03
> |
> | 4 | null | 2015-01-04 | 4 | d | 2015-01-04
> |
> | 5 | e | 2015-01-05 | 5 | e | 2015-01-05
> |
> | 6 | f | 2015-01-06 | 6 | f | 2015-01-06
> |
> | 7 | g | 2015-01-07 | 7 | g | 2015-01-07
> |
> | 7 | g | 2015-01-07 | 7 | g | 2015-01-07
> |
> | 9 | i | null | 9 | i | 2015-01-09
> |
> +++++++
> 11 rows selected (0.253 seconds)
> {code}
> CTAS assert:
> {code}
> 0: jdbc:drill:schema=dfs> create table test as select * from t1, t2 where
> t1.a1 = t2.a2;
> Query failed: RemoteRpcException: Failure while running fragment.[
> 83a1a356-b427-4dce-822f-6ae35ef9ca38 on atsqa4-134.qa.lab:31010 ]
> [ 83a1a356-b427-4dce-822f-6ae35ef9ca38 on atsqa4-134.qa.lab:31010 ]
> Error: exception while executing query: Failure while executing query.
> (state=,code=0)
> {code}
> From drillbit.log
> {code}
> 2015-03-20 23:40:30,017 [2af35011-91c9-7834-14b3-863cb0cf41d2:frag:0:0] ERROR
> o.a.d.e.w.f.AbstractStatusReporter - Error
> 83a1a356-b427-4dce-822f-6ae35ef9ca38: Failure while running fragment.
> java.lang.AssertionError: null
> at
> org.apache.drill.exec.physical.impl.project.ProjectRecordBatch.setupNewSchema(ProjectRecordBatch.java:347)
> ~[drill-java-exec-0.8.0-SNAPSHOT-rebuffed.jar:0.8.0-SNAPSHOT]
> at
> org.apache.drill.exec.record.AbstractSingleRecordBatch.innerNext(AbstractSingleRecordBatch.java:78)
> ~[drill-java-exec-0.8.0-SNAPSHOT-rebuffed.jar:0.8.0-SNAPSHOT]
> at
> org.apache.drill.exec.physical.impl.project.ProjectRecordBatch.innerNext(ProjectRecordBatch.java:134)
> ~[drill-java-exec-0.8.0-SNAPSHOT-rebuffed.jar:0.8.0-SNAPSHOT]
> at
> org.apache.drill.exec.record.AbstractRecordBatch.next(AbstractRecordBatch.java:142)
> ~[drill-java-exec-0.8.0-SNAPSHOT-rebuffed.jar:0.8.0-SNAPSHOT]
> at
> org.apache.drill.exec.physical.impl.validate.IteratorValidatorBatchIterator.next(IteratorValidatorBatchIterator.java:118)
> ~[drill-java-exec-0.8.0-SNAPSHOT-rebuffed.jar:0.8.0-SNAPSHOT]
> at
> org.apache.drill.exec.record.AbstractRecordBatch.next(AbstractRecordBatch.java:99)
> ~[drill-java-exec-0.8.0-SNAPSHOT-rebuffed.jar:0.8.0-SNAPSHOT]
> at
> org.apache.drill.exec.record.AbstractRecordBatch.next(AbstractRecordBatch.java:89)
> ~[drill-java-exec-0.8.0-SNAPSHOT-rebuffed.jar:0.8.0-SNAPSHOT]
> at
> org.apache.drill.exec.physical.impl.WriterRecordBatch.innerNext(WriterRecordBatch.java:102)
> ~[drill-java-exec-0.8.0-SNAPSHOT-rebuffed.jar:0.8.0-SNAPSHOT]
> at
> org.apache.drill.exec.record.AbstractRecordBatch.next(AbstractRecordBatch.java:142)
> ~[drill-java-exec-0.8.0-SNAPSHOT-rebuffed.jar:0.8.0-SNAPSHOT]
> at
> org.apache.drill.exec.physical.impl.validate.IteratorValidatorBatchIterator.next(IteratorValidatorBatchIterator.java:118)
> ~[drill-java-exec-0.8.0-SNAPSHOT-rebuffed.jar:0.8.0-SNAPSHOT]
> at
> org.apache.drill.exec.record.AbstractRecordBatch.next(AbstractRecordBatch.java:99)
> ~[drill-java-exec-0.8.0-SNAPSHOT-rebuffed.jar:0.8.0-SNAPSHOT]
> at
> org.apache.drill.exec.record.AbstractRecordBat
[jira] [Updated] (DRILL-2960) Default hive storage plugin missing from fresh drill install
[ https://issues.apache.org/jira/browse/DRILL-2960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Westin updated DRILL-2960: Fix Version/s: 1.0.0 > Default hive storage plugin missing from fresh drill install > > > Key: DRILL-2960 > URL: https://issues.apache.org/jira/browse/DRILL-2960 > Project: Apache Drill > Issue Type: Bug > Components: Storage - Hive >Affects Versions: 0.9.0 >Reporter: Krystal >Assignee: Venki Korukanti > Fix For: 1.0.0 > > > Installed drill on a fresh node. The default storage plugin for hive is > missing from the webUI. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-2960) Default hive storage plugin missing from fresh drill install
[ https://issues.apache.org/jira/browse/DRILL-2960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Westin updated DRILL-2960: Assignee: Jason Altekruse (was: Venki Korukanti) > Default hive storage plugin missing from fresh drill install > > > Key: DRILL-2960 > URL: https://issues.apache.org/jira/browse/DRILL-2960 > Project: Apache Drill > Issue Type: Bug > Components: Storage - Hive >Affects Versions: 0.9.0 >Reporter: Krystal >Assignee: Jason Altekruse > Fix For: 1.0.0 > > > Installed drill on a fresh node. The default storage plugin for hive is > missing from the webUI. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (DRILL-2411) Scalar SUM/AVG over empty result set returns no rows instead of NULL
[
https://issues.apache.org/jira/browse/DRILL-2411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Victoria Markman closed DRILL-2411.
---
> Scalar SUM/AVG over empty result set returns no rows instead of NULL
>
>
> Key: DRILL-2411
> URL: https://issues.apache.org/jira/browse/DRILL-2411
> Project: Apache Drill
> Issue Type: Bug
> Components: Execution - Relational Operators
>Reporter: Victoria Markman
>Assignee: Mehant Baid
>Priority: Critical
> Fix For: 1.0.0
>
>
> Queries below should return NULL:
> {code}
> 0: jdbc:drill:schema=dfs> select sum(a2) from t2 where 1=0;
> ++
> | EXPR$0 |
> ++
> ++
> No rows selected (0.08 seconds)
> 0: jdbc:drill:schema=dfs> select avg(a2) from t2 where 1=0;
> ++
> | EXPR$0 |
> ++
> ++
> No rows selected (0.074 seconds)
> {code}
> When grouped, result is correct:
> {code}
> 0: jdbc:drill:schema=dfs> select a2, sum(a2) from t2 where 1=0 group by a2;
> +++
> | a2 | EXPR$1 |
> +++
> +++
> No rows selected (0.11 seconds)
> {code}
> I'm not convinced and it is not very intuitive that correct result should be
> NULL, but this is what postgres returns and Aman thinks NULL is the correct
> behavior :)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DRILL-2411) Scalar SUM/AVG over empty result set returns no rows instead of NULL
[
https://issues.apache.org/jira/browse/DRILL-2411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14528951#comment-14528951
]
Victoria Markman commented on DRILL-2411:
-
Verified fixed in: 0.9.0
#Sun May 03 18:33:43 EDT 2015
git.commit.id.abbrev=10833d2
Tests are checked in under:
Functional/Passing/aggregation/bugs/drill-2411-[1234].sql
> Scalar SUM/AVG over empty result set returns no rows instead of NULL
>
>
> Key: DRILL-2411
> URL: https://issues.apache.org/jira/browse/DRILL-2411
> Project: Apache Drill
> Issue Type: Bug
> Components: Execution - Relational Operators
>Reporter: Victoria Markman
>Assignee: Mehant Baid
>Priority: Critical
> Fix For: 1.0.0
>
>
> Queries below should return NULL:
> {code}
> 0: jdbc:drill:schema=dfs> select sum(a2) from t2 where 1=0;
> ++
> | EXPR$0 |
> ++
> ++
> No rows selected (0.08 seconds)
> 0: jdbc:drill:schema=dfs> select avg(a2) from t2 where 1=0;
> ++
> | EXPR$0 |
> ++
> ++
> No rows selected (0.074 seconds)
> {code}
> When grouped, result is correct:
> {code}
> 0: jdbc:drill:schema=dfs> select a2, sum(a2) from t2 where 1=0 group by a2;
> +++
> | a2 | EXPR$1 |
> +++
> +++
> No rows selected (0.11 seconds)
> {code}
> I'm not convinced and it is not very intuitive that correct result should be
> NULL, but this is what postgres returns and Aman thinks NULL is the correct
> behavior :)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DRILL-2878) FragmentExecutor.closeOutResources() is not called if an exception happens in the Foreman before the fragment executor starts running
[
https://issues.apache.org/jira/browse/DRILL-2878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Westin updated DRILL-2878:
Assignee: Deneche A. Hakim (was: Chris Westin)
> FragmentExecutor.closeOutResources() is not called if an exception happens in
> the Foreman before the fragment executor starts running
> -
>
> Key: DRILL-2878
> URL: https://issues.apache.org/jira/browse/DRILL-2878
> Project: Apache Drill
> Issue Type: Bug
> Components: Execution - Flow
>Reporter: Deneche A. Hakim
>Assignee: Deneche A. Hakim
> Fix For: 1.0.0
>
>
> When the Foreman sets up the root FragmentExecutor and it needs to wait for
> data from the remote fragments, the fragment manager is recorded in the work
> bus and the root fragment executor is not run immediately.
> If an exception happens in the Foreman while setting up the remote fragments,
> the Foreman cancels all fragments and returns a FAILED message to the client.
> Because the root fragment executor was not run it will never call it's
> closeOutResources() method and it's fragment context will never be closed.
> You can easily reproduce this by running the following unit test:
> {noformat}
> org.apache.drill.exec.server.TestDrillbitResilience#failsWhenSendingFragments
> {noformat}
> although the test passes successfully because Drill does report the correct
> failure to the client, the memory leak is not detected and will show up after
> the test finishes
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DRILL-2274) Unable to allocate sv2 buffer after repeated attempts : JOIN, Order by used in query
[
https://issues.apache.org/jira/browse/DRILL-2274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Westin updated DRILL-2274:
Assignee: Deneche A. Hakim (was: Chris Westin)
> Unable to allocate sv2 buffer after repeated attempts : JOIN, Order by used
> in query
>
>
> Key: DRILL-2274
> URL: https://issues.apache.org/jira/browse/DRILL-2274
> Project: Apache Drill
> Issue Type: Bug
> Components: Execution - Relational Operators
>Reporter: Rahul Challapalli
>Assignee: Deneche A. Hakim
> Fix For: 1.0.0
>
> Attachments: data.json
>
>
> git.commit.id.abbrev=6676f2d
> The below query fails :
> {code}
> select sub1.uid from `data.json` sub1 inner join `data.json` sub2 on sub1.uid
> = sub2.uid order by sub1.uid;
> {code}
> Error from the logs :
> {code}
> 2015-02-20 00:24:08,431 [2b1981b0-149e-981b-f83f-512c587321d7:frag:1:2] ERROR
> o.a.d.e.w.f.AbstractStatusReporter - Error
> 66dba4ff-644c-4400-ab84-203256dc2600: Failure while running fragment.
> java.lang.RuntimeException:
> org.apache.drill.exec.memory.OutOfMemoryException: Unable to allocate sv2
> buffer after repeated attempts
> at
> org.apache.drill.exec.physical.impl.xsort.ExternalSortBatch.innerNext(ExternalSortBatch.java:307)
> ~[drill-java-exec-0.8.0-SNAPSHOT-rebuffed.jar:0.8.0-SNAPSHOT]
> at
> org.apache.drill.exec.record.AbstractRecordBatch.next(AbstractRecordBatch.java:142)
> ~[drill-java-exec-0.8.0-SNAPSHOT-rebuffed.jar:0.8.0-SNAPSHOT]
> at
> org.apache.drill.exec.physical.impl.validate.IteratorValidatorBatchIterator.next(IteratorValidatorBatchIterator.java:118)
> ~[drill-java-exec-0.8.0-SNAPSHOT-rebuffed.jar:0.8.0-SNAPSHOT]
> at
> org.apache.drill.exec.record.AbstractRecordBatch.next(AbstractRecordBatch.java:99)
> ~[drill-java-exec-0.8.0-SNAPSHOT-rebuffed.jar:0.8.0-SNAPSHOT]
> at
> org.apache.drill.exec.record.AbstractRecordBatch.next(AbstractRecordBatch.java:89)
> ~[drill-java-exec-0.8.0-SNAPSHOT-rebuffed.jar:0.8.0-SNAPSHOT]
> at
> org.apache.drill.exec.record.AbstractSingleRecordBatch.innerNext(AbstractSingleRecordBatch.java:51)
> ~[drill-java-exec-0.8.0-SNAPSHOT-rebuffed.jar:0.8.0-SNAPSHOT]
> at
> org.apache.drill.exec.physical.impl.svremover.RemovingRecordBatch.innerNext(RemovingRecordBatch.java:96)
> ~[drill-java-exec-0.8.0-SNAPSHOT-rebuffed.jar:0.8.0-SNAPSHOT]
> at
> org.apache.drill.exec.record.AbstractRecordBatch.next(AbstractRecordBatch.java:142)
> ~[drill-java-exec-0.8.0-SNAPSHOT-rebuffed.jar:0.8.0-SNAPSHOT]
> at
> org.apache.drill.exec.physical.impl.validate.IteratorValidatorBatchIterator.next(IteratorValidatorBatchIterator.java:118)
> ~[drill-java-exec-0.8.0-SNAPSHOT-rebuffed.jar:0.8.0-SNAPSHOT]
> at
> org.apache.drill.exec.physical.impl.BaseRootExec.next(BaseRootExec.java:67)
> ~[drill-java-exec-0.8.0-SNAPSHOT-rebuffed.jar:0.8.0-SNAPSHOT]
> at
> org.apache.drill.exec.physical.impl.SingleSenderCreator$SingleSenderRootExec.innerNext(SingleSenderCreator.java:97)
> ~[drill-java-exec-0.8.0-SNAPSHOT-rebuffed.jar:0.8.0-SNAPSHOT]
> at
> org.apache.drill.exec.physical.impl.BaseRootExec.next(BaseRootExec.java:57)
> ~[drill-java-exec-0.8.0-SNAPSHOT-rebuffed.jar:0.8.0-SNAPSHOT]
> at
> org.apache.drill.exec.work.fragment.FragmentExecutor.run(FragmentExecutor.java:116)
> ~[drill-java-exec-0.8.0-SNAPSHOT-rebuffed.jar:0.8.0-SNAPSHOT]
> at
> org.apache.drill.exec.work.WorkManager$RunnableWrapper.run(WorkManager.java:303)
> [drill-java-exec-0.8.0-SNAPSHOT-rebuffed.jar:0.8.0-SNAPSHOT]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> [na:1.7.0_71]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> [na:1.7.0_71]
> at java.lang.Thread.run(Thread.java:745) [na:1.7.0_71]
> Caused by: org.apache.drill.exec.memory.OutOfMemoryException: Unable to
> allocate sv2 buffer after repeated attempts
> at
> org.apache.drill.exec.physical.impl.xsort.ExternalSortBatch.newSV2(ExternalSortBatch.java:516)
> ~[drill-java-exec-0.8.0-SNAPSHOT-rebuffed.jar:0.8.0-SNAPSHOT]
> at
> org.apache.drill.exec.physical.impl.xsort.ExternalSortBatch.innerNext(ExternalSortBatch.java:305)
> ~[drill-java-exec-0.8.0-SNAPSHOT-rebuffed.jar:0.8.0-SNAPSHOT]
> ... 16 common frames omitted
> {code}
> On a different drillbit in the cluster, I found the below message for the
> same run
> {code}
> 2015-02-20 00:24:08,435 [BitServer-6] WARN
> o.a.d.exec.rpc.control.WorkEventBus - A fragment message arrived but there
> was no registered listener for that message: profile {
>state: FAILED
>error {
> error_id: "66dba4ff-644c-4400-ab84-203256dc2600"
> endpoint {
>address: "qa-node191
[jira] [Created] (DRILL-2961) Statement.setQueryTimeout() should throw a SQLException
Kunal Khatua created DRILL-2961: --- Summary: Statement.setQueryTimeout() should throw a SQLException Key: DRILL-2961 URL: https://issues.apache.org/jira/browse/DRILL-2961 Project: Apache Drill Issue Type: Bug Components: Client - JDBC Affects Versions: 1.0.0 Environment: RHEL 6.4 Reporter: Kunal Khatua Assignee: Daniel Barclay (Drill) Fix For: 1.0.0 When trying to set the timeout for a Drill Statement object, Drill does not report any SQLException which makes the developer incorrectly believe that a timeout has been set. The operation should throw the exception: java.sql.SQLException: Method not supported at org.apache.drill.jdbc.DrillStatement.setQueryTimeout(DrillStatement.java) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (DRILL-2960) Default hive storage plugin missing from fresh drill install
Krystal created DRILL-2960: -- Summary: Default hive storage plugin missing from fresh drill install Key: DRILL-2960 URL: https://issues.apache.org/jira/browse/DRILL-2960 Project: Apache Drill Issue Type: Bug Components: Storage - Hive Affects Versions: 0.9.0 Reporter: Krystal Assignee: Venki Korukanti Installed drill on a fresh node. The default storage plugin for hive is missing from the webUI. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (DRILL-658) Add support for multiple distinct counts without a grouping key.
[
https://issues.apache.org/jira/browse/DRILL-658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Victoria Markman closed DRILL-658.
--
> Add support for multiple distinct counts without a grouping key.
>
>
> Key: DRILL-658
> URL: https://issues.apache.org/jira/browse/DRILL-658
> Project: Apache Drill
> Issue Type: New Feature
> Components: Query Planning & Optimization
>Reporter: Chun Chang
>Assignee: Aman Sinha
> Fix For: 0.9.0
>
>
> postgres:
> foodmart=# select count(distinct(c_int)), count(distinct(c_bigint)),
> count(distinct(c_float4)), count(distinct(c_float8)) from data;
> count | count | count | count
> ---+---+---+---
> 21 |23 |22 |20
> (1 row)
> drill:
> 0: jdbc:drill:schema=dfs> select count(distinct(c_int)),
> count(distinct(c_bigint)), count(distinct(c_float4)),
> count(distinct(c_float8)) from data;
> Query failed: org.apache.drill.exec.rpc.RpcException: Remote failure while
> running query.[error_id: "658d1c88-3968-457f-82e1-26c76ff7b54b"
> endpoint {
> address: "qa-node120.qa.lab"
> user_port: 31010
> control_port: 31011
> data_port: 31012
> }
> error_type: 0
> message: "Failure while parsing sql. < CannotPlanException:[ Node
> [rel#5852:Subset#33.PHYSICAL.SINGLETON([]).[]] could not be implemented;
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DRILL-658) Add support for multiple distinct counts without a grouping key.
[
https://issues.apache.org/jira/browse/DRILL-658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14528857#comment-14528857
]
Victoria Markman commented on DRILL-658:
Verified fixed in 0.9.0
#Sun May 03 18:33:43 EDT 2015
git.commit.id.abbrev=10833d2
Tests checked in under: Functional/Passing/aggregation/scalar
> Add support for multiple distinct counts without a grouping key.
>
>
> Key: DRILL-658
> URL: https://issues.apache.org/jira/browse/DRILL-658
> Project: Apache Drill
> Issue Type: New Feature
> Components: Query Planning & Optimization
>Reporter: Chun Chang
>Assignee: Aman Sinha
> Fix For: 0.9.0
>
>
> postgres:
> foodmart=# select count(distinct(c_int)), count(distinct(c_bigint)),
> count(distinct(c_float4)), count(distinct(c_float8)) from data;
> count | count | count | count
> ---+---+---+---
> 21 |23 |22 |20
> (1 row)
> drill:
> 0: jdbc:drill:schema=dfs> select count(distinct(c_int)),
> count(distinct(c_bigint)), count(distinct(c_float4)),
> count(distinct(c_float8)) from data;
> Query failed: org.apache.drill.exec.rpc.RpcException: Remote failure while
> running query.[error_id: "658d1c88-3968-457f-82e1-26c76ff7b54b"
> endpoint {
> address: "qa-node120.qa.lab"
> user_port: 31010
> control_port: 31011
> data_port: 31012
> }
> error_type: 0
> message: "Failure while parsing sql. < CannotPlanException:[ Node
> [rel#5852:Subset#33.PHYSICAL.SINGLETON([]).[]] could not be implemented;
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DRILL-2816) system error does not display the original Exception message
[
https://issues.apache.org/jira/browse/DRILL-2816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Deneche A. Hakim updated DRILL-2816:
Attachment: DRILL-2816.2.patch.txt
fixed TestUserException
> system error does not display the original Exception message
>
>
> Key: DRILL-2816
> URL: https://issues.apache.org/jira/browse/DRILL-2816
> Project: Apache Drill
> Issue Type: Bug
> Components: Execution - Flow
>Affects Versions: 0.9.0
> Environment: 64e3ec52b93e9331aa5179e040eca19afece8317 | DRILL-2611:
> value vectors should report valid value count | 16.04.2015 @ 13:53:34 EDT
>Reporter: Khurram Faraaz
>Assignee: Deneche A. Hakim
> Fix For: 1.0.0
>
> Attachments: DRILL-2816.1.patch.txt, DRILL-2816.2.patch.txt
>
>
> The below SQL reported an assertion error on an earlier source level, however
> now it is not reported as an AssertionError on the sqlline prompt.
> {code}
> this is the output from an earlier level
> 0: jdbc:drill:> select max(columns[0]) from (select * from `countries.csv`
> offset 1) tmp order by tmp.columns[1];
> Query failed: AssertionError: star should have been expanded
> Error: exception while executing query: Failure while executing query.
> (state=,code=0)
> here is the output from current level, as mention in the Environment field of
> this JIRI
> 0: jdbc:drill:> select max(tmp.columns[0]) from (select * from
> `countries.csv` offset 1) tmp order by tmp.columns[1];
> Query failed: SYSTEM ERROR: Unexpected exception during fragment
> initialization: star should have been expanded
> [3bfba8e5-5449-4d15-a663-0677e9ae65da on centos-04.qa.lab:31010]
> Error: exception while executing query: Failure while executing query.
> (state=,code=0)
> 2015-04-17 23:24:56,720 [2ace69b7-760a-4977-6eb9-1a39e4c1bb07:foreman] INFO
> o.a.drill.exec.work.foreman.Foreman - State change requested. PENDING -->
> FAILED
> org.apache.drill.exec.work.foreman.ForemanException: Unexpected exception
> during fragment initialization: star should have been expanded
> at org.apache.drill.exec.work.foreman.Foreman.run(Foreman.java:211)
> [drill-java-exec-0.9.0-SNAPSHOT-rebuffed.jar:0.9.0-SNAPSHOT]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> [na:1.7.0_75]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> [na:1.7.0_75]
> at java.lang.Thread.run(Thread.java:745) [na:1.7.0_75]
> Caused by: java.lang.AssertionError: star should have been expanded
> at org.eigenbase.sql.validate.AggChecker.visit(AggChecker.java:81)
> ~[optiq-core-0.9-drill-r21.jar:na]
> at org.eigenbase.sql.validate.AggChecker.visit(AggChecker.java:31)
> ~[optiq-core-0.9-drill-r21.jar:na]
> at org.eigenbase.sql.SqlIdentifier.accept(SqlIdentifier.java:222)
> ~[optiq-core-0.9-drill-r21.jar:na]
> at
> org.eigenbase.sql.util.SqlBasicVisitor$ArgHandlerImpl.visitChild(SqlBasicVisitor.java:107)
> ~[optiq-core-0.9-drill-r21.jar:na]
> at org.eigenbase.sql.SqlOperator.acceptCall(SqlOperator.java:688)
> ~[optiq-core-0.9-drill-r21.jar:na]
> at org.eigenbase.sql.validate.AggChecker.visit(AggChecker.java:139)
> ~[optiq-core-0.9-drill-r21.jar:na]
> at org.eigenbase.sql.validate.AggChecker.visit(AggChecker.java:31)
> ~[optiq-core-0.9-drill-r21.jar:na]
> at org.eigenbase.sql.SqlCall.accept(SqlCall.java:125)
> ~[optiq-core-0.9-drill-r21.jar:na]
> at
> org.eigenbase.sql.util.SqlBasicVisitor$ArgHandlerImpl.visitChild(SqlBasicVisitor.java:107)
> ~[optiq-core-0.9-drill-r21.jar:na]
> at org.eigenbase.sql.SqlOperator.acceptCall(SqlOperator.java:688)
> ~[optiq-core-0.9-drill-r21.jar:na]
> at org.eigenbase.sql.validate.AggChecker.visit(AggChecker.java:139)
> ~[optiq-core-0.9-drill-r21.jar:na]
> at org.eigenbase.sql.validate.AggChecker.visit(AggChecker.java:31)
> ~[optiq-core-0.9-drill-r21.jar:na]
> at org.eigenbase.sql.SqlCall.accept(SqlCall.java:125)
> ~[optiq-core-0.9-drill-r21.jar:na]
> at
> org.eigenbase.sql.validate.AggregatingSelectScope.checkAggregateExpr(AggregatingSelectScope.java:155)
> ~[optiq-core-0.9-drill-r21.jar:na]
> at
> org.eigenbase.sql.validate.AggregatingSelectScope.validateExpr(AggregatingSelectScope.java:164)
> ~[optiq-core-0.9-drill-r21.jar:na]
> at
> org.eigenbase.sql.validate.OrderByScope.validateExpr(OrderByScope.java:100)
> ~[optiq-core-0.9-drill-r21.jar:na]
> at
> org.eigenbase.sql.validate.SqlValidatorImpl.validateExpr(SqlValidatorImpl.java:3150)
> ~[optiq-core-0.9-drill-r21.jar:na]
> at
> org.eigenbase.sql.validate.SqlValidatorImpl.validateOrderItem(SqlValidatorImpl.java:2965)
> ~[optiq-core-0.9-drill-r21.jar:na]
>
[jira] [Updated] (DRILL-2816) system error does not display the original Exception message
[
https://issues.apache.org/jira/browse/DRILL-2816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Deneche A. Hakim updated DRILL-2816:
Attachment: DRILL-2816.1.patch.txt
added ErrorHelper.getRootMessage() to compute the proper error message for
system errors.
This is the message displayed after the change:
{noformat}
0: jdbc:drill:zk=localhost:2181> select max(columns[0]) from (select * from
`countries.csv` offset 1) tmp order by tmp.columns[1];
Query failed: SYSTEM ERROR: java.lang.AssertionError: star should have been
expanded
[Error Id: 77d6a2ba-7894-4c0f-ac7f-1bd3f845eb21 on 172.30.1.91:31010]
Error: exception while executing query: Failure while executing query.
(state=,code=0)
{noformat}
PS: I will probably include this fix along other small fixes in a single
reviewable patch
> system error does not display the original Exception message
>
>
> Key: DRILL-2816
> URL: https://issues.apache.org/jira/browse/DRILL-2816
> Project: Apache Drill
> Issue Type: Bug
> Components: Execution - Flow
>Affects Versions: 0.9.0
> Environment: 64e3ec52b93e9331aa5179e040eca19afece8317 | DRILL-2611:
> value vectors should report valid value count | 16.04.2015 @ 13:53:34 EDT
>Reporter: Khurram Faraaz
>Assignee: Deneche A. Hakim
> Fix For: 1.0.0
>
> Attachments: DRILL-2816.1.patch.txt
>
>
> The below SQL reported an assertion error on an earlier source level, however
> now it is not reported as an AssertionError on the sqlline prompt.
> {code}
> this is the output from an earlier level
> 0: jdbc:drill:> select max(columns[0]) from (select * from `countries.csv`
> offset 1) tmp order by tmp.columns[1];
> Query failed: AssertionError: star should have been expanded
> Error: exception while executing query: Failure while executing query.
> (state=,code=0)
> here is the output from current level, as mention in the Environment field of
> this JIRI
> 0: jdbc:drill:> select max(tmp.columns[0]) from (select * from
> `countries.csv` offset 1) tmp order by tmp.columns[1];
> Query failed: SYSTEM ERROR: Unexpected exception during fragment
> initialization: star should have been expanded
> [3bfba8e5-5449-4d15-a663-0677e9ae65da on centos-04.qa.lab:31010]
> Error: exception while executing query: Failure while executing query.
> (state=,code=0)
> 2015-04-17 23:24:56,720 [2ace69b7-760a-4977-6eb9-1a39e4c1bb07:foreman] INFO
> o.a.drill.exec.work.foreman.Foreman - State change requested. PENDING -->
> FAILED
> org.apache.drill.exec.work.foreman.ForemanException: Unexpected exception
> during fragment initialization: star should have been expanded
> at org.apache.drill.exec.work.foreman.Foreman.run(Foreman.java:211)
> [drill-java-exec-0.9.0-SNAPSHOT-rebuffed.jar:0.9.0-SNAPSHOT]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> [na:1.7.0_75]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> [na:1.7.0_75]
> at java.lang.Thread.run(Thread.java:745) [na:1.7.0_75]
> Caused by: java.lang.AssertionError: star should have been expanded
> at org.eigenbase.sql.validate.AggChecker.visit(AggChecker.java:81)
> ~[optiq-core-0.9-drill-r21.jar:na]
> at org.eigenbase.sql.validate.AggChecker.visit(AggChecker.java:31)
> ~[optiq-core-0.9-drill-r21.jar:na]
> at org.eigenbase.sql.SqlIdentifier.accept(SqlIdentifier.java:222)
> ~[optiq-core-0.9-drill-r21.jar:na]
> at
> org.eigenbase.sql.util.SqlBasicVisitor$ArgHandlerImpl.visitChild(SqlBasicVisitor.java:107)
> ~[optiq-core-0.9-drill-r21.jar:na]
> at org.eigenbase.sql.SqlOperator.acceptCall(SqlOperator.java:688)
> ~[optiq-core-0.9-drill-r21.jar:na]
> at org.eigenbase.sql.validate.AggChecker.visit(AggChecker.java:139)
> ~[optiq-core-0.9-drill-r21.jar:na]
> at org.eigenbase.sql.validate.AggChecker.visit(AggChecker.java:31)
> ~[optiq-core-0.9-drill-r21.jar:na]
> at org.eigenbase.sql.SqlCall.accept(SqlCall.java:125)
> ~[optiq-core-0.9-drill-r21.jar:na]
> at
> org.eigenbase.sql.util.SqlBasicVisitor$ArgHandlerImpl.visitChild(SqlBasicVisitor.java:107)
> ~[optiq-core-0.9-drill-r21.jar:na]
> at org.eigenbase.sql.SqlOperator.acceptCall(SqlOperator.java:688)
> ~[optiq-core-0.9-drill-r21.jar:na]
> at org.eigenbase.sql.validate.AggChecker.visit(AggChecker.java:139)
> ~[optiq-core-0.9-drill-r21.jar:na]
> at org.eigenbase.sql.validate.AggChecker.visit(AggChecker.java:31)
> ~[optiq-core-0.9-drill-r21.jar:na]
> at org.eigenbase.sql.SqlCall.accept(SqlCall.java:125)
> ~[optiq-core-0.9-drill-r21.jar:na]
> at
> org.eigenbase.sql.validate.AggregatingSelectScope.checkAggregateExpr(AggregatingSelectScope.java:155)
> ~[optiq-core-0.9
[jira] [Updated] (DRILL-2848) Disable decimal data type by default
[ https://issues.apache.org/jira/browse/DRILL-2848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mehant Baid updated DRILL-2848: --- Assignee: Jinfeng Ni (was: Mehant Baid) > Disable decimal data type by default > > > Key: DRILL-2848 > URL: https://issues.apache.org/jira/browse/DRILL-2848 > Project: Apache Drill > Issue Type: Bug > Components: Execution - Data Types >Reporter: Mehant Baid >Assignee: Jinfeng Ni >Priority: Critical > Fix For: 1.0.0 > > Attachments: DRILL-2848-part1.patch, DRILL-2848-part2.patch > > > Due to the difference in the storage format of decimal data type in parquet > versus the in-memory format within Drill using the decimal data type is not > performant. Also some of the rules for calculating the scale and precision > need to be changed. These two concerns will be addressed post 1.0.0 release > and to prevent users from running into this we are disabling decimal data > type by default. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-2848) Disable decimal data type by default
[ https://issues.apache.org/jira/browse/DRILL-2848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mehant Baid updated DRILL-2848: --- Attachment: DRILL-2848-part2.patch DRILL-2848-part1.patch [~jni] please review RB: https://reviews.apache.org/r/33833/ https://reviews.apache.org/r/33834/ > Disable decimal data type by default > > > Key: DRILL-2848 > URL: https://issues.apache.org/jira/browse/DRILL-2848 > Project: Apache Drill > Issue Type: Bug > Components: Execution - Data Types >Reporter: Mehant Baid >Assignee: Mehant Baid >Priority: Critical > Fix For: 1.0.0 > > Attachments: DRILL-2848-part1.patch, DRILL-2848-part2.patch > > > Due to the difference in the storage format of decimal data type in parquet > versus the in-memory format within Drill using the decimal data type is not > performant. Also some of the rules for calculating the scale and precision > need to be changed. These two concerns will be addressed post 1.0.0 release > and to prevent users from running into this we are disabling decimal data > type by default. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-2697) Pause injections should pause indefinitely until signalled
[ https://issues.apache.org/jira/browse/DRILL-2697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudheesh Katkam updated DRILL-2697: --- Assignee: Chris Westin (was: Sudheesh Katkam) > Pause injections should pause indefinitely until signalled > -- > > Key: DRILL-2697 > URL: https://issues.apache.org/jira/browse/DRILL-2697 > Project: Apache Drill > Issue Type: Improvement > Components: Execution - Flow >Affects Versions: 0.9.0 >Reporter: Sudheesh Katkam >Assignee: Chris Westin > Fix For: 1.0.0 > > > Currently injected pauses make threads sleep for a specified time. This can > be an enhanced to stop the thread indefinitely using a CountDownLatch. It is > quite similar to how cancellation works. > Tasks: > (a) Add another message to RPC layer to signal paused remote threads to > resume (through ControlHandler) by counting down. Complications if the thread > has not reached the pause site yet. > (b) Add resume signal (like ctrl-c) to sqlline > (further enhancement: another signal to trigger pause from sqlline) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DRILL-2697) Pause injections should pause indefinitely until signalled
[ https://issues.apache.org/jira/browse/DRILL-2697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14528740#comment-14528740 ] Sudheesh Katkam commented on DRILL-2697: Review board: https://reviews.apache.org/r/33770/ > Pause injections should pause indefinitely until signalled > -- > > Key: DRILL-2697 > URL: https://issues.apache.org/jira/browse/DRILL-2697 > Project: Apache Drill > Issue Type: Improvement > Components: Execution - Flow >Affects Versions: 0.9.0 >Reporter: Sudheesh Katkam >Assignee: Sudheesh Katkam > Fix For: 1.0.0 > > > Currently injected pauses make threads sleep for a specified time. This can > be an enhanced to stop the thread indefinitely using a CountDownLatch. It is > quite similar to how cancellation works. > Tasks: > (a) Add another message to RPC layer to signal paused remote threads to > resume (through ControlHandler) by counting down. Complications if the thread > has not reached the pause site yet. > (b) Add resume signal (like ctrl-c) to sqlline > (further enhancement: another signal to trigger pause from sqlline) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-2697) Pause injections should pause indefinitely until signalled
[ https://issues.apache.org/jira/browse/DRILL-2697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudheesh Katkam updated DRILL-2697: --- Fix Version/s: (was: 1.1.0) 1.0.0 > Pause injections should pause indefinitely until signalled > -- > > Key: DRILL-2697 > URL: https://issues.apache.org/jira/browse/DRILL-2697 > Project: Apache Drill > Issue Type: Improvement > Components: Execution - Flow >Affects Versions: 0.9.0 >Reporter: Sudheesh Katkam >Assignee: Sudheesh Katkam > Fix For: 1.0.0 > > > Currently injected pauses make threads sleep for a specified time. This can > be an enhanced to stop the thread indefinitely using a CountDownLatch. It is > quite similar to how cancellation works. > Tasks: > (a) Add another message to RPC layer to signal paused remote threads to > resume (through ControlHandler) by counting down. Complications if the thread > has not reached the pause site yet. > (b) Add resume signal (like ctrl-c) to sqlline > (further enhancement: another signal to trigger pause from sqlline) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (DRILL-2697) Pause injections should pause indefinitely until signalled
[ https://issues.apache.org/jira/browse/DRILL-2697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudheesh Katkam reassigned DRILL-2697: -- Assignee: Sudheesh Katkam > Pause injections should pause indefinitely until signalled > -- > > Key: DRILL-2697 > URL: https://issues.apache.org/jira/browse/DRILL-2697 > Project: Apache Drill > Issue Type: Improvement > Components: Execution - Flow >Affects Versions: 0.9.0 >Reporter: Sudheesh Katkam >Assignee: Sudheesh Katkam > Fix For: 1.0.0 > > > Currently injected pauses make threads sleep for a specified time. This can > be an enhanced to stop the thread indefinitely using a CountDownLatch. It is > quite similar to how cancellation works. > Tasks: > (a) Add another message to RPC layer to signal paused remote threads to > resume (through ControlHandler) by counting down. Complications if the thread > has not reached the pause site yet. > (b) Add resume signal (like ctrl-c) to sqlline > (further enhancement: another signal to trigger pause from sqlline) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (DRILL-2617) Errors in the execution stack will cause DeferredException to throw an IllegalStateException
[
https://issues.apache.org/jira/browse/DRILL-2617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Deneche A. Hakim resolved DRILL-2617.
-
Resolution: Fixed
DeferredException.close() is no longer called by FragmentExecutor. The only
class that calls DeferredException.close() is EventProcessor but the exception
is only used as a local variable and once the exception is closed, no other
method is called.
> Errors in the execution stack will cause DeferredException to throw an
> IllegalStateException
>
>
> Key: DRILL-2617
> URL: https://issues.apache.org/jira/browse/DRILL-2617
> Project: Apache Drill
> Issue Type: Bug
> Components: Execution - Flow
>Affects Versions: 0.8.0
>Reporter: Deneche A. Hakim
>Assignee: Deneche A. Hakim
> Fix For: 1.0.0
>
>
> When a query fails while executing, the following events happen:
> - the exception is added to {{FragmentContext.deferredException}}
> - the {{FragmentExecutor}} reports the failure to the client through the
> {{Foreman}}
> - the {{FragmentExecutor}} closes the {{DeferredException}}
> - {{DeferredException.close()}} throws back the original exception
> - {{FragmentExecutor.run()}} catches the exception and try to add it to the
> {{DeferredException}}
> - {{DeferredException.addException()}} throws an {{IllegalStateException}}
> because it's already closed.
> You can reproduce this by querying the following json file, which contains an
> extra ":"
> {code}
> { "a1": 0 , "b1": "a"}
> { "a1": 1 , "b1": "b"}
> { "a1": 2 , "b1": "c"}
> { "a1":: 3 , "b1": "c"}
> {code}
> Sqlline will dispaly both the error message sent by the Foreman and the
> IllegalStateException:
> {noformat}
> 0: jdbc:drill:zk=local> select * from `t.json`;
> Query failed: Query stopped., Unexpected character (':' (code 58)): expected
> a valid value (number, String, array, object, 'true', 'false' or 'null')
> at [Source: org.apache.drill.exec.vector.complex.fn.JsonReader@161188d3;
> line: 3, column: 9] [ b55f7d53-0e88-456f-bb12-160cacae9222 on
> administorsmbp2.attlocal.net:31010 ]
> Error: exception while executing query: Failure while executing query.
> (state=,code=0)
> 0: jdbc:drill:zk=local> Exception in thread "WorkManager-2"
> java.lang.IllegalStateException
> at
> com.google.common.base.Preconditions.checkState(Preconditions.java:133)
> at
> org.apache.drill.common.DeferredException.addException(DeferredException.java:47)
> at
> org.apache.drill.common.DeferredException.addThrowable(DeferredException.java:61)
> at
> org.apache.drill.exec.ops.FragmentContext.fail(FragmentContext.java:135)
> at
> org.apache.drill.exec.work.fragment.FragmentExecutor.run(FragmentExecutor.java:181)
> 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)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DRILL-1542) Early fragment termination causes non running intermediate fragments to error
[ https://issues.apache.org/jira/browse/DRILL-1542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14528700#comment-14528700 ] Deneche A. Hakim commented on DRILL-1542: - Looking at the log and the git history of FragmentExecutor, I suspect this was caused when FragmentExecutor.receivingFragmentFinished() tried to call root.receivingFragmentFinished() but root was null because the fragment didn't start running yet. If this is the case, then you should not see this error anymore but DRILL-2878 is still not fixed and it can happen for intermediate fragment executors as well. Do we have instructions to try and reproduce this so we can confirm it is fixed ? > Early fragment termination causes non running intermediate fragments to error > - > > Key: DRILL-1542 > URL: https://issues.apache.org/jira/browse/DRILL-1542 > Project: Apache Drill > Issue Type: Bug > Components: Execution - Flow >Reporter: Jacques Nadeau >Assignee: Deneche A. Hakim >Priority: Critical > Fix For: 1.0.0 > > > Caused by: java.lang.NullPointerException: null > at > org.apache.drill.exec.work.fragment.FragmentExecutor.receivingFragmentFinished(FragmentExecutor.java:75) > > ~[drill-java-exec-0.6.0-incubating-SNAPSHOT-rebuffed.jar:0.6.0-incubating-SNAPSHOT] > at > org.apache.drill.exec.work.batch.ControlHandlerImpl.receivingFragmentFinished(ControlHandlerImpl.java:174) > > ~[drill-java-exec-0.6.0-incubating-SNAPSHOT-rebuffed.jar:0.6.0-incubating-SNAPSHOT] > at > org.apache.drill.exec.work.batch.ControlHandlerImpl.handle(ControlHandlerImpl.java:76) > > ~[drill-java-exec-0.6.0-incubating-SNAPSHOT-rebuffed.jar:0.6.0-incubating-SNAPSHOT] > at > org.apache.drill.exec.rpc.control.ControlServer.handle(ControlServer.java:60) > ~[drill-java-exec-0.6.0-incubating-SNAPSHOT-rebuffed.jar:0.6.0-incubating-SNAPSHOT] > at > org.apache.drill.exec.rpc.control.ControlServer.handle(ControlServer.java:38) > ~[drill-java-exec-0.6.0-incubating-SNAPSHOT-rebuffed.jar:0.6.0-incubating-SNAPSHOT] > at org.apache.drill.exec.rpc.RpcBus.handle(RpcBus.java:56) > ~[drill-java-exec-0.6.0-incubating-SNAPSHOT-rebuffed.jar:0.6.0-incubating-SNAPSHOT] > at > org.apache.drill.exec.rpc.RpcBus$InboundHandler.decode(RpcBus.java:191) > ~[drill-java-exec-0.6.0-incubating-SNAPSHOT-rebuffed.jar:0.6.0-incubating-SNAPSHOT] > at > org.apache.drill.exec.rpc.RpcBus$InboundHandler.decode(RpcBus.java:171) > ~[drill-java-exec-0.6.0-incubating-SNAPSHOT-rebuffed.jar:0.6.0-incubating-SNAPSHOT] > at > io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:89) > [netty-codec-4.0.20.Final.jar:4.0.20.Final] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DRILL-2408) CTAS should not create empty folders when underlying query returns no results
[
https://issues.apache.org/jira/browse/DRILL-2408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14528681#comment-14528681
]
Deneche A. Hakim commented on DRILL-2408:
-
I changed this to 1.0.0 as it is in a reviewable state. If it doesn't pass the
review we can change it back to 1.2.0
> CTAS should not create empty folders when underlying query returns no results
> -
>
> Key: DRILL-2408
> URL: https://issues.apache.org/jira/browse/DRILL-2408
> Project: Apache Drill
> Issue Type: Bug
> Components: Storage - Writer
>Affects Versions: 0.8.0
>Reporter: Aman Sinha
>Assignee: Aman Sinha
> Fix For: 1.0.0
>
> Attachments: DRILL-2408.1.patch.txt, DRILL-2408.2.patch.txt,
> DRILL-2408.3.patch.txt, DRILL-2408.4.patch.txt, DRILL-2408.5.patch.txt,
> DRILL-2408.6.patch.txt, DRILL-2408.7.patch.txt
>
>
> {noformat}
> 0: jdbc:drill:schema=dfs> select c_integer, c_bigint, c_date, c_time,
> c_varchar from j4 where c_bigint is null;
> ++++++
> | c_integer | c_bigint | c_date | c_time | c_varchar |
> ++++++
> ++++++
> No rows selected (0.126 seconds)
> 0: jdbc:drill:schema=dfs> create table ctas_t6(c1,c2,c3,c4,c5) as select
> c_integer, c_bigint, c_date, c_time, c_varchar from j4 where c_bigint is null;
> ++---+
> | Fragment | Number of records written |
> ++---+
> | 0_0| 0 |
> ++---+
> 1 row selected (0.214 seconds)
> 0: jdbc:drill:schema=dfs> select * from ctas_t6;
> Query failed: IndexOutOfBoundsException: Index: 0, Size: 0
> Error: exception while executing query: Failure while executing query.
> (state=,code=0)
> {noformat}
> parquet file was not created, but directory was:
> {noformat}
> [Mon Apr 06 09:03:41
> root@/mapr/vmarkman.cluster.com/drill/testdata/joins/ctas_t6 ] # pwd
> /mapr/vmarkman.cluster.com/drill/testdata/joins/ctas_t6
> [Mon Apr 06 09:03:45
> root@/mapr/vmarkman.cluster.com/drill/testdata/joins/ctas_t6 ] # ls -l
> total 0
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DRILL-2408) CTAS should not create empty folders when underlying query returns no results
[
https://issues.apache.org/jira/browse/DRILL-2408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Deneche A. Hakim updated DRILL-2408:
Attachment: DRILL-2408.7.patch.txt
rebased on top of master
fixed BaseTestQuery to use one single temp folder for all drillbits, instead of
creating a different folder for each drillbit
all unit tests are passing along with functional and tpch100
> CTAS should not create empty folders when underlying query returns no results
> -
>
> Key: DRILL-2408
> URL: https://issues.apache.org/jira/browse/DRILL-2408
> Project: Apache Drill
> Issue Type: Bug
> Components: Storage - Writer
>Affects Versions: 0.8.0
>Reporter: Aman Sinha
>Assignee: Deneche A. Hakim
> Fix For: 1.0.0
>
> Attachments: DRILL-2408.1.patch.txt, DRILL-2408.2.patch.txt,
> DRILL-2408.3.patch.txt, DRILL-2408.4.patch.txt, DRILL-2408.5.patch.txt,
> DRILL-2408.6.patch.txt, DRILL-2408.7.patch.txt
>
>
> {noformat}
> 0: jdbc:drill:schema=dfs> select c_integer, c_bigint, c_date, c_time,
> c_varchar from j4 where c_bigint is null;
> ++++++
> | c_integer | c_bigint | c_date | c_time | c_varchar |
> ++++++
> ++++++
> No rows selected (0.126 seconds)
> 0: jdbc:drill:schema=dfs> create table ctas_t6(c1,c2,c3,c4,c5) as select
> c_integer, c_bigint, c_date, c_time, c_varchar from j4 where c_bigint is null;
> ++---+
> | Fragment | Number of records written |
> ++---+
> | 0_0| 0 |
> ++---+
> 1 row selected (0.214 seconds)
> 0: jdbc:drill:schema=dfs> select * from ctas_t6;
> Query failed: IndexOutOfBoundsException: Index: 0, Size: 0
> Error: exception while executing query: Failure while executing query.
> (state=,code=0)
> {noformat}
> parquet file was not created, but directory was:
> {noformat}
> [Mon Apr 06 09:03:41
> root@/mapr/vmarkman.cluster.com/drill/testdata/joins/ctas_t6 ] # pwd
> /mapr/vmarkman.cluster.com/drill/testdata/joins/ctas_t6
> [Mon Apr 06 09:03:45
> root@/mapr/vmarkman.cluster.com/drill/testdata/joins/ctas_t6 ] # ls -l
> total 0
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DRILL-2408) CTAS should not create empty folders when underlying query returns no results
[
https://issues.apache.org/jira/browse/DRILL-2408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Deneche A. Hakim updated DRILL-2408:
Fix Version/s: (was: 1.2.0)
1.0.0
> CTAS should not create empty folders when underlying query returns no results
> -
>
> Key: DRILL-2408
> URL: https://issues.apache.org/jira/browse/DRILL-2408
> Project: Apache Drill
> Issue Type: Bug
> Components: Storage - Writer
>Affects Versions: 0.8.0
>Reporter: Aman Sinha
>Assignee: Aman Sinha
> Fix For: 1.0.0
>
> Attachments: DRILL-2408.1.patch.txt, DRILL-2408.2.patch.txt,
> DRILL-2408.3.patch.txt, DRILL-2408.4.patch.txt, DRILL-2408.5.patch.txt,
> DRILL-2408.6.patch.txt, DRILL-2408.7.patch.txt
>
>
> {noformat}
> 0: jdbc:drill:schema=dfs> select c_integer, c_bigint, c_date, c_time,
> c_varchar from j4 where c_bigint is null;
> ++++++
> | c_integer | c_bigint | c_date | c_time | c_varchar |
> ++++++
> ++++++
> No rows selected (0.126 seconds)
> 0: jdbc:drill:schema=dfs> create table ctas_t6(c1,c2,c3,c4,c5) as select
> c_integer, c_bigint, c_date, c_time, c_varchar from j4 where c_bigint is null;
> ++---+
> | Fragment | Number of records written |
> ++---+
> | 0_0| 0 |
> ++---+
> 1 row selected (0.214 seconds)
> 0: jdbc:drill:schema=dfs> select * from ctas_t6;
> Query failed: IndexOutOfBoundsException: Index: 0, Size: 0
> Error: exception while executing query: Failure while executing query.
> (state=,code=0)
> {noformat}
> parquet file was not created, but directory was:
> {noformat}
> [Mon Apr 06 09:03:41
> root@/mapr/vmarkman.cluster.com/drill/testdata/joins/ctas_t6 ] # pwd
> /mapr/vmarkman.cluster.com/drill/testdata/joins/ctas_t6
> [Mon Apr 06 09:03:45
> root@/mapr/vmarkman.cluster.com/drill/testdata/joins/ctas_t6 ] # ls -l
> total 0
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DRILL-2408) CTAS should not create empty folders when underlying query returns no results
[
https://issues.apache.org/jira/browse/DRILL-2408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Deneche A. Hakim updated DRILL-2408:
Assignee: Aman Sinha (was: Deneche A. Hakim)
> CTAS should not create empty folders when underlying query returns no results
> -
>
> Key: DRILL-2408
> URL: https://issues.apache.org/jira/browse/DRILL-2408
> Project: Apache Drill
> Issue Type: Bug
> Components: Storage - Writer
>Affects Versions: 0.8.0
>Reporter: Aman Sinha
>Assignee: Aman Sinha
> Fix For: 1.0.0
>
> Attachments: DRILL-2408.1.patch.txt, DRILL-2408.2.patch.txt,
> DRILL-2408.3.patch.txt, DRILL-2408.4.patch.txt, DRILL-2408.5.patch.txt,
> DRILL-2408.6.patch.txt, DRILL-2408.7.patch.txt
>
>
> {noformat}
> 0: jdbc:drill:schema=dfs> select c_integer, c_bigint, c_date, c_time,
> c_varchar from j4 where c_bigint is null;
> ++++++
> | c_integer | c_bigint | c_date | c_time | c_varchar |
> ++++++
> ++++++
> No rows selected (0.126 seconds)
> 0: jdbc:drill:schema=dfs> create table ctas_t6(c1,c2,c3,c4,c5) as select
> c_integer, c_bigint, c_date, c_time, c_varchar from j4 where c_bigint is null;
> ++---+
> | Fragment | Number of records written |
> ++---+
> | 0_0| 0 |
> ++---+
> 1 row selected (0.214 seconds)
> 0: jdbc:drill:schema=dfs> select * from ctas_t6;
> Query failed: IndexOutOfBoundsException: Index: 0, Size: 0
> Error: exception while executing query: Failure while executing query.
> (state=,code=0)
> {noformat}
> parquet file was not created, but directory was:
> {noformat}
> [Mon Apr 06 09:03:41
> root@/mapr/vmarkman.cluster.com/drill/testdata/joins/ctas_t6 ] # pwd
> /mapr/vmarkman.cluster.com/drill/testdata/joins/ctas_t6
> [Mon Apr 06 09:03:45
> root@/mapr/vmarkman.cluster.com/drill/testdata/joins/ctas_t6 ] # ls -l
> total 0
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DRILL-2802) Projecting dir[n] by itself results in projecting of all columns
[
https://issues.apache.org/jira/browse/DRILL-2802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacques Nadeau updated DRILL-2802:
--
Fix Version/s: (was: 1.0.0)
1.2.0
> Projecting dir[n] by itself results in projecting of all columns
>
>
> Key: DRILL-2802
> URL: https://issues.apache.org/jira/browse/DRILL-2802
> Project: Apache Drill
> Issue Type: Bug
> Components: Query Planning & Optimization
>Affects Versions: 0.9.0
>Reporter: Victoria Markman
>Assignee: Jinfeng Ni
> Fix For: 1.2.0
>
>
> {code}
> 0: jdbc:drill:schema=dfs> select dir1 from bigtable limit 1;
> +++++
> | a1 | b1 | c1 |dir1|
> +++++
> | 1 | a | 2015-01-01 | 01 |
> +++++
> 1 row selected (0.189 seconds)
> 0: jdbc:drill:schema=dfs> select dir0 from bigtable limit 1;
> +++++
> | a1 | b1 | c1 |dir0|
> +++++
> | 1 | a | 2015-01-01 | 2015 |
> +++++
> 1 row selected (0.193 seconds)
> {code}
> In explain plan, I don't see project:
> {code}
> 0: jdbc:drill:schema=dfs> explain plan for select dir0 from bigtable;
> +++
> |text|json|
> +++
> | 00-00Screen
> 00-01 Scan(groupscan=[ParquetGroupScan [entries=[ReadEntryWithPath
> [path=maprfs:/test/bigtable/2015/01/4_0_0.parquet], ReadEntryWithPath
> [path=maprfs:/test/bigtable/2015/01/3_0_0.parquet], ReadEntryWithPath
> [path=maprfs:/test/bigtable/2015/01/5_0_0.parquet], ReadEntryWithPath
> [path=maprfs:/test/bigtable/2015/01/1_0_0.parquet], ReadEntryWithPath
> [path=maprfs:/test/bigtable/2015/01/2_0_0.parquet], ReadEntryWithPath
> [path=maprfs:/test/bigtable/2015/01/0_0_0.parquet], ReadEntryWithPath
> [path=maprfs:/test/bigtable/2015/02/0_0_0.parquet], ReadEntryWithPath
> [path=maprfs:/test/bigtable/2015/03/0_0_0.parquet], ReadEntryWithPath
> [path=maprfs:/test/bigtable/2015/04/0_0_0.parquet], ReadEntryWithPath
> [path=maprfs:/test/bigtable/2016/01/parquet.file], ReadEntryWithPath
> [path=maprfs:/test/bigtable/2016/parquet.file]],
> selectionRoot=/test/bigtable, numFiles=11, columns=[`dir0`]]])
> {code}
> If you project both dir0 and dir1, both columns are projected with the
> correct result:
> {code}
> 0: jdbc:drill:schema=dfs> select dir0, dir1 from bigtable;
> +++
> |dir0|dir1|
> +++
> | 2015 | 01 |
> | 2015 | 01 |
> | 2015 | 01 |
> | 2015 | 01 |
> | 2015 | 01 |
> | 2015 | 01 |
> | 2015 | 01 |
> | 2015 | 01 |
> | 2015 | 01 |
> {code}
> {code}
> [Wed Apr 15 14:09:47 root@/mapr/vmarkman.cluster.com/test/bigtable ] # ls -R
> .:
> 2015 2016
> ./2015:
> 01 02 03 04
> ./2015/01:
> 0_0_0.parquet 1_0_0.parquet 2_0_0.parquet 3_0_0.parquet 4_0_0.parquet
> 5_0_0.parquet
> ./2015/02:
> 0_0_0.parquet
> ./2015/03:
> 0_0_0.parquet
> ./2015/04:
> 0_0_0.parquet
> ./2016:
> 01 parquet.file
> ./2016/01:
> parquet.file
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DRILL-2894) FixedValueVectors shouldn't set it's data buffer to null when it fails to allocate it
[ https://issues.apache.org/jira/browse/DRILL-2894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Deneche A. Hakim updated DRILL-2894: Assignee: Hanifi Gunes (was: Deneche A. Hakim) > FixedValueVectors shouldn't set it's data buffer to null when it fails to > allocate it > - > > Key: DRILL-2894 > URL: https://issues.apache.org/jira/browse/DRILL-2894 > Project: Apache Drill > Issue Type: Bug > Components: Execution - Data Types >Reporter: Deneche A. Hakim >Assignee: Hanifi Gunes > Fix For: 1.0.0 > > > this is related to DRILL-2893 > In _FixedValueVectors.java_ the following allocation methods will set the > _data_ field to null if they fail to allocate properly: > - _allocateNewSafe()_ > - _allocateNew(int valueCount)_ > - _reAlloc()_ > This will cause 2 problems: > 1. both _allocateNew(int valueCount)_ and _reAlloc()_ will throw a > _NullPointerException_ when it fails to allocate. This is somewhat properly > taken care of by the calling code > 2. when the operators are cleaning up, calling _clear()_ on a vector with a > null data buffer will throw a _NullPointerException_ preventing the cleanup > from finishing up properly > _VariableLengthVectors.java_ has a similar problem -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-2893) ScanBatch throws a NullPointerException instead of returning OUT_OF_MEMORY
[
https://issues.apache.org/jira/browse/DRILL-2893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Deneche A. Hakim updated DRILL-2893:
Assignee: Steven Phillips (was: Deneche A. Hakim)
> ScanBatch throws a NullPointerException instead of returning OUT_OF_MEMORY
> --
>
> Key: DRILL-2893
> URL: https://issues.apache.org/jira/browse/DRILL-2893
> Project: Apache Drill
> Issue Type: Sub-task
> Components: Execution - Relational Operators
>Reporter: Deneche A. Hakim
>Assignee: Steven Phillips
> Fix For: 1.0.0
>
>
> - set _drill.exec.memory.top.max_ in _drill-override.conf_ to some low value
> (I used _7500_)
> - disable hash aggregate (set _plannder.enable_hashagg_ to false)
> - disable exchanges (set _plannder.disable_exchanges_ to true)
> - run the following query
> {noformat}
> select count(*) from (select * from dfs.data.`tpch1/lineitem.parquet` order
> by l_orderkey);
> {noformat}
> and you should get the following error message:
> {noformat}
> Query failed: SYSTEM ERROR: null
> Fragment 0:0
> [e05ff3c2-e130-449e-b721-b3442796e29b on 172.30.1.1:31010]
> {noformat}
> We have 2 problems here:
> 1st:
> - ScanBatch detects that it can't allocate it's field value vectors and right
> before returning _OUT_OF_MEMORY_ downstream it calls _clear() on the field
> vectors
> - one of those vectors actually threw a NullPointerException in it's
> _allocateNew()_ methods after it cleared it's buffer and couldn't allocate a
> new one
> - when ScanBatch tries to clean that vector, it will throw a
> NullPointerException which will prevent the ScanBatch from returning
> _OUT_OF_MEMORY_ and will cancel the query instead
> 2nd problem:
> - once the query has been canceled, _ScanBatch.cleanup()_ will throw another
> _NullPointerException_ when cleaning the field vectors, which will prevent
> the cleanup of the remaining resources and will cause a memory leak
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DRILL-2895) AbstractRecordBatch.buildSchema() should properly handle OUT_OF_MEMORY outcome
[ https://issues.apache.org/jira/browse/DRILL-2895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Deneche A. Hakim updated DRILL-2895: Assignee: Steven Phillips (was: Deneche A. Hakim) > AbstractRecordBatch.buildSchema() should properly handle OUT_OF_MEMORY outcome > -- > > Key: DRILL-2895 > URL: https://issues.apache.org/jira/browse/DRILL-2895 > Project: Apache Drill > Issue Type: Sub-task > Components: Execution - Relational Operators >Reporter: Deneche A. Hakim >Assignee: Steven Phillips > Fix For: 1.0.0 > > > currently, and in the unlikely event where we hit an out of memory exception > while building the schema, operators that extend _AbstractRecordBatch_ don't > handle this properly. > Extend AbstractRecordBatch.BatchState to allow reporting OUT_OF_MEMORY back > to the root. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-2920) properly handle OutOfMemoryException
[ https://issues.apache.org/jira/browse/DRILL-2920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Deneche A. Hakim updated DRILL-2920: Assignee: Steven Phillips (was: Deneche A. Hakim) > properly handle OutOfMemoryException > > > Key: DRILL-2920 > URL: https://issues.apache.org/jira/browse/DRILL-2920 > Project: Apache Drill > Issue Type: Sub-task > Components: Execution - Flow, Execution - Relational Operators >Reporter: Deneche A. Hakim >Assignee: Steven Phillips > Fix For: 1.0.0 > > > OutOfMemoryException can happen in multiple places: > - when creating the root fragment context > - when creating a remote fragment context > - inside the execution stack > We should catch those exception and handle them properly, reporting a "memory > error" to the user -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-2947) AllocationHelper.allocateNew() doesn't have a consistent behavior when it can't allocate
[
https://issues.apache.org/jira/browse/DRILL-2947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Deneche A. Hakim updated DRILL-2947:
Assignee: Steven Phillips (was: Deneche A. Hakim)
> AllocationHelper.allocateNew() doesn't have a consistent behavior when it
> can't allocate
>
>
> Key: DRILL-2947
> URL: https://issues.apache.org/jira/browse/DRILL-2947
> Project: Apache Drill
> Issue Type: Sub-task
> Components: Execution - Flow, Execution - Relational Operators
>Reporter: Deneche A. Hakim
>Assignee: Steven Phillips
>Priority: Critical
> Fix For: 1.0.0
>
>
> AllocationHelper.allocateNew(...) has the following implementation:
> {code}
> public static boolean allocateNew(ValueVector v, int valueCount){
> if (v instanceof FixedWidthVector) {
> ((FixedWidthVector) v).allocateNew(valueCount);
> return true;
> } else {
> return v.allocateNewSafe();
> }
> }
> {code}
> If it can't allocate the memory it will either return false or throw an
> _OutOfMemoryRuntimeException_ depending on the class of v.
> Some operators that use this method, like _NestedLoopJoinBatch_ don't check
> if _allocateNew()_ returns false assuming it will throw an exception instead.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DRILL-2905) RootExec implementations should properly handle IterOutcome.OUT_OF_MEMORY
[ https://issues.apache.org/jira/browse/DRILL-2905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Deneche A. Hakim updated DRILL-2905: Assignee: Steven Phillips (was: Deneche A. Hakim) > RootExec implementations should properly handle IterOutcome.OUT_OF_MEMORY > - > > Key: DRILL-2905 > URL: https://issues.apache.org/jira/browse/DRILL-2905 > Project: Apache Drill > Issue Type: Sub-task > Components: Execution - Flow, Execution - Relational Operators >Reporter: Deneche A. Hakim >Assignee: Steven Phillips > Fix For: 1.0.0 > > > RootExec implementations should throw an _OutOfMemoryRuntimeException_ when > _incoming.next()_ returns _OUT_OF_MEMORY_ > FragmentExecutor.run() already handles such exceptions and returns the proper > error message to the client -- This message was sent by Atlassian JIRA (v6.3.4#6332)
