[jira] [Updated] (DRILL-2150) Create an abstraction for repeated value vectors.
[ https://issues.apache.org/jira/browse/DRILL-2150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mehant Baid updated DRILL-2150: --- Assignee: Hanifi Gunes (was: Mehant Baid) > Create an abstraction for repeated value vectors. > - > > Key: DRILL-2150 > URL: https://issues.apache.org/jira/browse/DRILL-2150 > Project: Apache Drill > Issue Type: Sub-task > Components: Execution - Data Types >Reporter: Hanifi Gunes >Assignee: Hanifi Gunes >Priority: Critical > Fix For: 1.0.0 > > > This sub-task is concerned about creating an abstraction for repeated value > vectors. The existing abstraction seems invalid. The purpose is to provide a > minimal interface that enables code re-usability. > The proposal is to preserve existing functionalities such as exposing group > count, group size as well as providing low level access to underlying offsets > and data vectors. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DRILL-2150) Create an abstraction for repeated value vectors.
[ https://issues.apache.org/jira/browse/DRILL-2150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14536212#comment-14536212 ] Mehant Baid commented on DRILL-2150: +1. > Create an abstraction for repeated value vectors. > - > > Key: DRILL-2150 > URL: https://issues.apache.org/jira/browse/DRILL-2150 > Project: Apache Drill > Issue Type: Sub-task > Components: Execution - Data Types >Reporter: Hanifi Gunes >Assignee: Mehant Baid >Priority: Critical > Fix For: 1.0.0 > > > This sub-task is concerned about creating an abstraction for repeated value > vectors. The existing abstraction seems invalid. The purpose is to provide a > minimal interface that enables code re-usability. > The proposal is to preserve existing functionalities such as exposing group > count, group size as well as providing low level access to underlying offsets > and data vectors. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-2941) Update RPC layer to avoid writing local data messages to socket
[ https://issues.apache.org/jira/browse/DRILL-2941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Nadeau updated DRILL-2941: -- Attachment: DRILL-2941.patch Updated patch to ensure thread affinity > Update RPC layer to avoid writing local data messages to socket > --- > > Key: DRILL-2941 > URL: https://issues.apache.org/jira/browse/DRILL-2941 > Project: Apache Drill > Issue Type: Bug > Components: Execution - RPC >Reporter: Jacques Nadeau >Assignee: Steven Phillips > Fix For: 1.0.0 > > Attachments: DRILL-2941.patch, DRILL-2941.patch > > > Right now, if we send a fragment record batch to localhost, we still traverse > the RPC layer. We should short-circuit this path. This is especially > important in light of the mux and demux exchanges. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (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:all-tabpanel ] Deneche A. Hakim resolved DRILL-1542. - Resolution: Cannot Reproduce This doesn't seem to be happening any longer in the current code base. > 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] [Updated] (DRILL-2971) If Bit<>Bit connection is unexpectedly closed and we were already blocked on writing to socket, we'll stay forever in ResettableBarrier.await()
[ https://issues.apache.org/jira/browse/DRILL-2971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Deneche A. Hakim updated DRILL-2971: Assignee: Steven Phillips (was: Deneche A. Hakim) > If Bit<>Bit connection is unexpectedly closed and we were already blocked on > writing to socket, we'll stay forever in ResettableBarrier.await() > --- > > Key: DRILL-2971 > URL: https://issues.apache.org/jira/browse/DRILL-2971 > Project: Apache Drill > Issue Type: Bug > Components: Execution - RPC >Reporter: Jacques Nadeau >Assignee: Steven Phillips > Fix For: 1.0.0 > > Attachments: DRILL-2971.patch > > > We need to reset the ResettableBarrier if the connection dies so that the > message can be failed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DRILL-2971) If Bit<>Bit connection is unexpectedly closed and we were already blocked on writing to socket, we'll stay forever in ResettableBarrier.await()
[ https://issues.apache.org/jira/browse/DRILL-2971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14536121#comment-14536121 ] Deneche A. Hakim commented on DRILL-2971: - assigned to [~sphillips] for additional review and commit > If Bit<>Bit connection is unexpectedly closed and we were already blocked on > writing to socket, we'll stay forever in ResettableBarrier.await() > --- > > Key: DRILL-2971 > URL: https://issues.apache.org/jira/browse/DRILL-2971 > Project: Apache Drill > Issue Type: Bug > Components: Execution - RPC >Reporter: Jacques Nadeau >Assignee: Steven Phillips > Fix For: 1.0.0 > > Attachments: DRILL-2971.patch > > > We need to reset the ResettableBarrier if the connection dies so that the > message can be failed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DRILL-2976) Set default of extended JSON support for output to false until issues are resolved
[ https://issues.apache.org/jira/browse/DRILL-2976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14536052#comment-14536052 ] Mehant Baid commented on DRILL-2976: +1, couple of minor comments. We don't need the convert_toSIMPLEJSON any more, can we remove it? Also if we need to keep it then we should simply add that as a name alias to the function convert_toJSON Just wanted to mention that changing the option to enable extended json would still not bind to the convert_toEXTENDEDJSON function automatically, to make that happen we will have to change DrillOptiq. > Set default of extended JSON support for output to false until issues are > resolved > -- > > Key: DRILL-2976 > URL: https://issues.apache.org/jira/browse/DRILL-2976 > Project: Apache Drill > Issue Type: Bug > Components: Storage - JSON >Reporter: Jacques Nadeau >Assignee: Jason Altekruse > Fix For: 1.0.0 > > Attachments: 2976-part2.patch, DRILL-2976.1.patch.txt > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-3003) NPE with the query where on clause contains select with scalar aggregate
[
https://issues.apache.org/jira/browse/DRILL-3003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Victoria Markman updated DRILL-3003:
Summary: NPE with the query where on clause contains select with scalar
aggregate (was: NPE on )
> NPE with the query where on clause contains select with scalar aggregate
>
>
> Key: DRILL-3003
> URL: https://issues.apache.org/jira/browse/DRILL-3003
> Project: Apache Drill
> Issue Type: Bug
> Components: SQL Parser
>Reporter: Victoria Markman
>Assignee: Aman Sinha
>Priority: Minor
>
> Calcite throws null pointer exception:
> {code}
> 0: jdbc:drill:schema=dfs> select * from t1 right outer join t2 on (t1.a1 =
> t2.a2) and t1.a1 = ( select max(a3) from t3 );
> Error: PARSE ERROR: java.lang.NullPointerException
> [Error Id: 645fa4fb-7547-455f-a4b9-896fb6aa914e on atsqa4-133.qa.lab:31010]
> (state=,code=0)
> {code}
> Correct query works:
> {code}
> 0: jdbc:drill:schema=dfs> select * from t1 right outer join t2 on (t1.a1 =
> t2.a2) where t1.a1 = ( select max(a3) from t3 );
> +++++++
> | a1 | b1 | c1 | a2 | b2 | c2
> |
> +++++++
> | 3 | c | 2015-01-03 | 3 | c | 2015-01-03
> |
> +++++++
> 1 row selected (0.236 seconds)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DRILL-3003) NPE on
[
https://issues.apache.org/jira/browse/DRILL-3003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Victoria Markman updated DRILL-3003:
Summary: NPE on (was: NPE on incorrect query (and instead of where
clause))
> NPE on
> ---
>
> Key: DRILL-3003
> URL: https://issues.apache.org/jira/browse/DRILL-3003
> Project: Apache Drill
> Issue Type: Bug
> Components: SQL Parser
>Reporter: Victoria Markman
>Assignee: Aman Sinha
>Priority: Minor
>
> Calcite throws null pointer exception:
> {code}
> 0: jdbc:drill:schema=dfs> select * from t1 right outer join t2 on (t1.a1 =
> t2.a2) and t1.a1 = ( select max(a3) from t3 );
> Error: PARSE ERROR: java.lang.NullPointerException
> [Error Id: 645fa4fb-7547-455f-a4b9-896fb6aa914e on atsqa4-133.qa.lab:31010]
> (state=,code=0)
> {code}
> Correct query works:
> {code}
> 0: jdbc:drill:schema=dfs> select * from t1 right outer join t2 on (t1.a1 =
> t2.a2) where t1.a1 = ( select max(a3) from t3 );
> +++++++
> | a1 | b1 | c1 | a2 | b2 | c2
> |
> +++++++
> | 3 | c | 2015-01-03 | 3 | c | 2015-01-03
> |
> +++++++
> 1 row selected (0.236 seconds)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DRILL-3003) NPE on incorrect query (and instead of where clause)
[
https://issues.apache.org/jira/browse/DRILL-3003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14536044#comment-14536044
]
Victoria Markman commented on DRILL-3003:
-
As Jason pointed out, this is perfectly valid query as well as this one:
{code}
0: jdbc:drill:schema=dfs> select * from t1 right outer join t2 on (t1.a1 =
t2.a2 and t1.a1 = ( select max(a3) from t3 ));
Error: PARSE ERROR: java.lang.NullPointerException
[Error Id: afe70dd7-199f-4dae-802e-2b5e08f13af8 on atsqa4-133.qa.lab:31010]
(state=,code=0)
{code}
> NPE on incorrect query (and instead of where clause)
>
>
> Key: DRILL-3003
> URL: https://issues.apache.org/jira/browse/DRILL-3003
> Project: Apache Drill
> Issue Type: Bug
> Components: SQL Parser
>Reporter: Victoria Markman
>Assignee: Aman Sinha
>Priority: Minor
>
> Calcite throws null pointer exception:
> {code}
> 0: jdbc:drill:schema=dfs> select * from t1 right outer join t2 on (t1.a1 =
> t2.a2) and t1.a1 = ( select max(a3) from t3 );
> Error: PARSE ERROR: java.lang.NullPointerException
> [Error Id: 645fa4fb-7547-455f-a4b9-896fb6aa914e on atsqa4-133.qa.lab:31010]
> (state=,code=0)
> {code}
> Correct query works:
> {code}
> 0: jdbc:drill:schema=dfs> select * from t1 right outer join t2 on (t1.a1 =
> t2.a2) where t1.a1 = ( select max(a3) from t3 );
> +++++++
> | a1 | b1 | c1 | a2 | b2 | c2
> |
> +++++++
> | 3 | c | 2015-01-03 | 3 | c | 2015-01-03
> |
> +++++++
> 1 row selected (0.236 seconds)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DRILL-2958) Move Drill to alternative cost-based planner for Join planning
[ https://issues.apache.org/jira/browse/DRILL-2958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14536032#comment-14536032 ] Jinfeng Ni commented on DRILL-2958: --- Copy from review board about a summary of change in the patch: Drill current use VolcanoPlanner in join planning. This planner has two known issues: 1. The search space is increased exponentially with increased # of tables joined. If query has more than > 10 tables join, the planning time itself could be minutes, if not longer. 2. Drill did not enable a rule to swap both sides of join, due to the search space problem. We only do a swap join afterwards. See DRILL-2236. This means the join order chosen by Drill's VolcanoPlanner might not be optimal. To address the above two issues, we are going to provide another planner for the purpose of join ordering planning. This planner will use a different optimization rules, and the search space is not increased exponentially with # of table. The main logic of this new planner: 1) Let VolcanoPlanner do all the rule transformations same as the current planner's logical planning, except for the join permutation rule. 2) After that, pass to HepPlanner with Calcite LOPT optimization rule, to let it do the join ordering. Feed with the HepPlanner with Drill's RelMetaDataProvider, to leverage the statistics (rowcount) available in Drill's table/files. 3) Continue with the same physical planning as before. With the limited statistics available in Drill, the new planner seems to produce better query plan than the current, for several TPCH queries. Preliminary performance results show this planner run faster than the existing one, and the join plan seems to be same or better than the plan chosen by the existing planner. > Move Drill to alternative cost-based planner for Join planning > -- > > Key: DRILL-2958 > URL: https://issues.apache.org/jira/browse/DRILL-2958 > Project: Apache Drill > Issue Type: Bug > Components: Query Planning & Optimization >Reporter: Jacques Nadeau >Assignee: Jinfeng Ni > Fix For: 1.0.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (DRILL-3003) NPE on incorrect query (and instead of where clause)
Victoria Markman created DRILL-3003:
---
Summary: NPE on incorrect query (and instead of where clause)
Key: DRILL-3003
URL: https://issues.apache.org/jira/browse/DRILL-3003
Project: Apache Drill
Issue Type: Bug
Components: SQL Parser
Reporter: Victoria Markman
Assignee: Aman Sinha
Priority: Minor
Calcite throws null pointer exception:
{code}
0: jdbc:drill:schema=dfs> select * from t1 right outer join t2 on (t1.a1 =
t2.a2) and t1.a1 = ( select max(a3) from t3 );
Error: PARSE ERROR: java.lang.NullPointerException
[Error Id: 645fa4fb-7547-455f-a4b9-896fb6aa914e on atsqa4-133.qa.lab:31010]
(state=,code=0)
{code}
Correct query works:
{code}
0: jdbc:drill:schema=dfs> select * from t1 right outer join t2 on (t1.a1 =
t2.a2) where t1.a1 = ( select max(a3) from t3 );
+++++++
| a1 | b1 | c1 | a2 | b2 | c2 |
+++++++
| 3 | c | 2015-01-03 | 3 | c | 2015-01-03 |
+++++++
1 row selected (0.236 seconds)
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DRILL-2958) Move Drill to alternative cost-based planner for Join planning
[ https://issues.apache.org/jira/browse/DRILL-2958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14536031#comment-14536031 ] Jinfeng Ni commented on DRILL-2958: --- Reviewboard link: https://reviews.apache.org/r/34006/ > Move Drill to alternative cost-based planner for Join planning > -- > > Key: DRILL-2958 > URL: https://issues.apache.org/jira/browse/DRILL-2958 > Project: Apache Drill > Issue Type: Bug > Components: Query Planning & Optimization >Reporter: Jacques Nadeau >Assignee: Jinfeng Ni > Fix For: 1.0.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-3002) Can't plan inequality queries when scalar subquery has an expression with at least one distinct aggregate
[
https://issues.apache.org/jira/browse/DRILL-3002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aman Sinha updated DRILL-3002:
--
Fix Version/s: 1.1.0
> Can't plan inequality queries when scalar subquery has an expression with at
> least one distinct aggregate
> -
>
> Key: DRILL-3002
> URL: https://issues.apache.org/jira/browse/DRILL-3002
> Project: Apache Drill
> Issue Type: Bug
> Components: Query Planning & Optimization
>Affects Versions: 1.0.0
>Reporter: Victoria Markman
>Assignee: Aman Sinha
> Fix For: 1.1.0
>
>
> Fails with mix of of distinct/non distinct scalar aggregates on the same
> column:
> {code}
> 0: jdbc:drill:schema=dfs> select * from t1 where a1 > ( select count(a2) +
> count(distinct a2) from t2);
> Error: SYSTEM ERROR: This query cannot be planned possibly due to either a
> cartesian join or an inequality join
> [Error Id: 69c0feda-6284-4a76-b1f7-bbc43a099a20 on atsqa4-133.qa.lab:31010]
> (state=,code=0)
> {code}
> Works with two distinct aggregates in expression:
> {code}
> 0: jdbc:drill:schema=dfs> select * from t1 where a1 > ( select count(distinct
> a2) + count(distinct a2) from t2);
> ++++
> | a1 | b1 | c1 |
> ++++
> ++++
> No rows selected (0.226 seconds)
> {code}
> Fails with two distinct aggregates on different columns:
> {code}
> 0: jdbc:drill:schema=dfs> select * from t1 where a1 > ( select count(distinct
> a2) + count(distinct b2) from t2);
> Error: SYSTEM ERROR: This query cannot be planned possibly due to either a
> cartesian join or an inequality join
> [Error Id: 80b10ec8-add6-45fd-8f1a-1e68852936a2 on atsqa4-133.qa.lab:31010]
> (state=,code=0)
> 0: jdbc:drill:schema=dfs>
> {code}
> Works with two non distinct scalar aggregates:
> {code}
> 0: jdbc:drill:schema=dfs> select * from t1 where a1 > ( select count(a2) +
> count(a2) from t2);
> ++++
> | a1 | b1 | c1 |
> ++++
> ++++
> No rows selected (0.244 seconds)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (DRILL-3002) Can't plan inequality queries when scalar subquery has an expression with at least one distinct aggregate
[
https://issues.apache.org/jira/browse/DRILL-3002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aman Sinha reassigned DRILL-3002:
-
Assignee: Aman Sinha (was: Jinfeng Ni)
> Can't plan inequality queries when scalar subquery has an expression with at
> least one distinct aggregate
> -
>
> Key: DRILL-3002
> URL: https://issues.apache.org/jira/browse/DRILL-3002
> Project: Apache Drill
> Issue Type: Bug
> Components: Query Planning & Optimization
>Affects Versions: 1.0.0
>Reporter: Victoria Markman
>Assignee: Aman Sinha
>
> Fails with mix of of distinct/non distinct scalar aggregates on the same
> column:
> {code}
> 0: jdbc:drill:schema=dfs> select * from t1 where a1 > ( select count(a2) +
> count(distinct a2) from t2);
> Error: SYSTEM ERROR: This query cannot be planned possibly due to either a
> cartesian join or an inequality join
> [Error Id: 69c0feda-6284-4a76-b1f7-bbc43a099a20 on atsqa4-133.qa.lab:31010]
> (state=,code=0)
> {code}
> Works with two distinct aggregates in expression:
> {code}
> 0: jdbc:drill:schema=dfs> select * from t1 where a1 > ( select count(distinct
> a2) + count(distinct a2) from t2);
> ++++
> | a1 | b1 | c1 |
> ++++
> ++++
> No rows selected (0.226 seconds)
> {code}
> Fails with two distinct aggregates on different columns:
> {code}
> 0: jdbc:drill:schema=dfs> select * from t1 where a1 > ( select count(distinct
> a2) + count(distinct b2) from t2);
> Error: SYSTEM ERROR: This query cannot be planned possibly due to either a
> cartesian join or an inequality join
> [Error Id: 80b10ec8-add6-45fd-8f1a-1e68852936a2 on atsqa4-133.qa.lab:31010]
> (state=,code=0)
> 0: jdbc:drill:schema=dfs>
> {code}
> Works with two non distinct scalar aggregates:
> {code}
> 0: jdbc:drill:schema=dfs> select * from t1 where a1 > ( select count(a2) +
> count(a2) from t2);
> ++++
> | a1 | b1 | c1 |
> ++++
> ++++
> No rows selected (0.244 seconds)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (DRILL-2570) Broken JDBC-All Jar packaging can cause missing XML classes
[ https://issues.apache.org/jira/browse/DRILL-2570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Barclay (Drill) reassigned DRILL-2570: - Assignee: Daniel Barclay (Drill) (was: Parth Chandra) > Broken JDBC-All Jar packaging can cause missing XML classes > --- > > Key: DRILL-2570 > URL: https://issues.apache.org/jira/browse/DRILL-2570 > Project: Apache Drill > Issue Type: Bug > Components: Tools, Build & Test >Reporter: Daniel Barclay (Drill) >Assignee: Daniel Barclay (Drill) > Fix For: 1.0.0 > > Attachments: DRILL-2570.1.patch.txt, ElementTraversal.rtf, > xerces-error.rtf > > > [Transcribed from other medium:] > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > - - - - - - - - - - - > When starting Spotfire Server using JDBC driver an error see attachment > (xerces-error) is produced. > This error is then resolved by adding the jars/3rdparty/xercesImpl-2.11.0.jar > from the drillbit package to the classpath for the JDBC client driver. > Then the following error is observed. See attachment (ElementTraversal). > This requires to add jars/3rdparty/xml-apis-1.4.01.jar to the classpath from > the drillbit package. > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > - - - - - - - - - - - > The issue is Tomcat and Spotfire Server does not show any errors and starts > up fine without the Drill JDBC driver. Once the Drill driver is added the > application server fails to start with the errors shown. > Adding the 2 jars to the classpath then resolves the issue. > I have not looked at all the JDBC driver classes, but it is important to note > that the error occurs when the JDBC driver is added and resolved by adding 2 > jars from the drillbit package. > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > - - - - - - - - - - - > > I do not see Drill classes in the stack trace. This seems to be a Tomcat > > configuration issue. > I suspect another possibility: that the Drill JDBC-all Jar file contains a > stray reference to the unfound class (SAXParserFactoryImpl) in some file in > META-INF/services (left over from some package whose classes we either > excluded or renamed (with "shading") > Xxx, Yyy: Can you try this?: > (Temporarily) removing the added XML Jar files from the class path to > re-confirm the problem. > Move the Drill JDBC-all Jar file to be last on the class path (and remove > ). > Report whether the symptoms change. > Thanks. > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > - - - - - - - - - - - -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DRILL-2993) SQLLine hangs when we cancel a query in the middle of displaying results
[
https://issues.apache.org/jira/browse/DRILL-2993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14536018#comment-14536018
]
Use OTHER Daniel Barclay commented on DRILL-2993:
-
Rahul,
I may have lost your message about the data file.
Where's the data file for DRILL-2993?
Daniel
> SQLLine hangs when we cancel a query in the middle of displaying results
>
>
> Key: DRILL-2993
> URL: https://issues.apache.org/jira/browse/DRILL-2993
> Project: Apache Drill
> Issue Type: Bug
> Components: Execution - Flow
>Reporter: Rahul Challapalli
>Assignee: Daniel Barclay (Drill)
>
> git.commit.id.abbrev=8c706e6
> The data set contains 1 million records. I cancelled the below query after
> displaying around ~400,000 records. All subsequent queries fail
> {code}
> 0: jdbc:drill:schema=dfs_eea>select * from `mobile.json`;
> .
> .
> Cancel after displaying 400,000 records
> 0: jdbc:drill:schema=dfs_eea>use dfs.drillTestDir;
>
> This hangs indefinitely
> {code}
> Since the data is large, I did not attach it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (DRILL-3002) Can't plan inequality queries when scalar subquery has an expression with at least one distinct aggregate
Victoria Markman created DRILL-3002:
---
Summary: Can't plan inequality queries when scalar subquery has an
expression with at least one distinct aggregate
Key: DRILL-3002
URL: https://issues.apache.org/jira/browse/DRILL-3002
Project: Apache Drill
Issue Type: Bug
Components: Query Planning & Optimization
Affects Versions: 1.0.0
Reporter: Victoria Markman
Assignee: Jinfeng Ni
Fails with mix of of distinct/non distinct scalar aggregates on the same column:
{code}
0: jdbc:drill:schema=dfs> select * from t1 where a1 > ( select count(a2) +
count(distinct a2) from t2);
Error: SYSTEM ERROR: This query cannot be planned possibly due to either a
cartesian join or an inequality join
[Error Id: 69c0feda-6284-4a76-b1f7-bbc43a099a20 on atsqa4-133.qa.lab:31010]
(state=,code=0)
{code}
Works with two distinct aggregates in expression:
{code}
0: jdbc:drill:schema=dfs> select * from t1 where a1 > ( select count(distinct
a2) + count(distinct a2) from t2);
++++
| a1 | b1 | c1 |
++++
++++
No rows selected (0.226 seconds)
{code}
Fails with two distinct aggregates on different columns:
{code}
0: jdbc:drill:schema=dfs> select * from t1 where a1 > ( select count(distinct
a2) + count(distinct b2) from t2);
Error: SYSTEM ERROR: This query cannot be planned possibly due to either a
cartesian join or an inequality join
[Error Id: 80b10ec8-add6-45fd-8f1a-1e68852936a2 on atsqa4-133.qa.lab:31010]
(state=,code=0)
0: jdbc:drill:schema=dfs>
{code}
Works with two non distinct scalar aggregates:
{code}
0: jdbc:drill:schema=dfs> select * from t1 where a1 > ( select count(a2) +
count(a2) from t2);
++++
| a1 | b1 | c1 |
++++
++++
No rows selected (0.244 seconds)
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DRILL-2003) bootstrap-storage-plugins.json is not merged properly
[ https://issues.apache.org/jira/browse/DRILL-2003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14536006#comment-14536006 ] Jason Altekruse commented on DRILL-2003: This is likely still an issue, as the boostrap storage plugins are only used the first time we start Drill, I am moving this to 1.1. For now anyone who is having issues getting storage plugins registered with Drill through the boostrap files can use the Rest API to upload and update storage plugins. Documentation available here: http://drill.apache.org/docs/plugin-configuration-introduction/ > bootstrap-storage-plugins.json is not merged properly > - > > Key: DRILL-2003 > URL: https://issues.apache.org/jira/browse/DRILL-2003 > Project: Apache Drill > Issue Type: Bug > Components: Metadata >Affects Versions: 0.7.0 >Reporter: Rahul Challapalli >Assignee: Jason Altekruse > Fix For: 1.1.0 > > > Drill not picking up the bootstrap-storage-plugins.json from the conf > directory. I made sure that the Zookeeper's drill directory is empty and the > conf directory is in the classpath. > It looks like there is an issue with the merge with the same file in the jar > file provided with drill. > This worked with 0.6.0 but seems to be broken with the current 0.7.0 release -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DRILL-2976) Set default of extended JSON support for output to false until issues are resolved
[ https://issues.apache.org/jira/browse/DRILL-2976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14535958#comment-14535958 ] Jason Altekruse commented on DRILL-2976: +1 on the first patch, I have added a part 2 patch to also disable extended json in the convert_toJSON function. [~mehant] Can you do a quick review on the second patch? > Set default of extended JSON support for output to false until issues are > resolved > -- > > Key: DRILL-2976 > URL: https://issues.apache.org/jira/browse/DRILL-2976 > Project: Apache Drill > Issue Type: Bug > Components: Storage - JSON >Reporter: Jacques Nadeau >Assignee: Jason Altekruse > Fix For: 1.0.0 > > Attachments: 2976-part2.patch, DRILL-2976.1.patch.txt > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-2976) Set default of extended JSON support for output to false until issues are resolved
[ https://issues.apache.org/jira/browse/DRILL-2976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Altekruse updated DRILL-2976: --- Attachment: 2976-part2.patch > Set default of extended JSON support for output to false until issues are > resolved > -- > > Key: DRILL-2976 > URL: https://issues.apache.org/jira/browse/DRILL-2976 > Project: Apache Drill > Issue Type: Bug > Components: Storage - JSON >Reporter: Jacques Nadeau >Assignee: Jason Altekruse > Fix For: 1.0.0 > > Attachments: 2976-part2.patch, DRILL-2976.1.patch.txt > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-2989) TPCDS Query corrupts Drillbits and causing subsequent unrelated queries to hang (and timeout)
[ https://issues.apache.org/jira/browse/DRILL-2989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kunal Khatua updated DRILL-2989: Attachment: DRILL-2989.tgz 02_dri100_TPCDS_4.0.2.29870.GA_drill-1058d52_run1_-20150508_1135.tgz 06_dri100_TPCH_4.0.2.29870.GA_drill-1058d52_run1_-20150508_1131.tgz 06_dri100_TPCH_4.0.2.29870.GA_drill-1058d52_run1_-20150508_1142.tgz JStack logs are attached and available in DRILL-2989.tgz The Drillbit logs for each query are in their respective timestamped gzipped tarballs. Order of execution: 06_dri100_TPCH_4.0.2.29870.GA_drill-1058d52_run1_-20150508_1131 02_dri100_TPCDS_4.0.2.29870.GA_drill-1058d52_run1_-20150508_1135 06_dri100_TPCH_4.0.2.29870.GA_drill-1058d52_run1_-20150508_1142 > TPCDS Query corrupts Drillbits and causing subsequent unrelated queries to > hang (and timeout) > - > > Key: DRILL-2989 > URL: https://issues.apache.org/jira/browse/DRILL-2989 > Project: Apache Drill > Issue Type: Bug >Affects Versions: 1.0.0 > Environment: RHEL 6.4 >Reporter: Kunal Khatua >Priority: Critical > Fix For: 1.0.0 > > Attachments: > 02_dri100_TPCDS_4.0.2.29870.GA_drill-1058d52_run1_-20150508_1135.tgz, > 06_dri100_TPCH_4.0.2.29870.GA_drill-1058d52_run1_-20150508_1131.tgz, > 06_dri100_TPCH_4.0.2.29870.GA_drill-1058d52_run1_-20150508_1142.tgz, > DRILL-2989.tgz, dBit_TPC-DBug.jstack.out > > > 30-node setup has TPC-H Drill (SF100) and TPC-DS Drill (SF100) in two > different workspaces. > TPC-H Query 6 is executed on the cluster successfully, followed by execution > of TPC-DS Query 2; which hangs during the executeQuery() operation. After a > 2min timeout, the TPC-H Query is executed on the cluster, but this also hangs > during the fetching of rows from the ResultSet. The profile page for the > second attempt at TPC-H query 6 shows it as pending. > The TPC-H schema is in its own workspace which exposes the directories as > tables. > The TPC-DS schema is in its own workspace, which has views on top of the > directories containing the actual tables' data. > TPCH-06 > [INFO] Will be using Drillbit on 10.10.120.114 > [QUERYID] 2ab41296-1420-ee4b-2617-849b63eb11b4 > [STAT] TOTAL TIME : 7420 msec > TPCDS-02 > [INFO] Will be using Drillbit on 10.10.120.117 > [TIME OUT] Query took more than 120 sec. > TPCH-06 > [INFO] Will be using Drillbit on 10.10.120.130 > [TIME OUT] Query took more than 120 sec. > [QUERYID] 2ab41027-abcc-c48a-7e3c-957bb069f452 > [STAT] TOTAL TIME : 120017 msec -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DRILL-2570) Broken JDBC-All Jar packaging can cause missing XML classes
[ https://issues.apache.org/jira/browse/DRILL-2570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14535936#comment-14535936 ] Parth Chandra commented on DRILL-2570: -- merged in commit c2bd698 > Broken JDBC-All Jar packaging can cause missing XML classes > --- > > Key: DRILL-2570 > URL: https://issues.apache.org/jira/browse/DRILL-2570 > Project: Apache Drill > Issue Type: Bug > Components: Tools, Build & Test >Reporter: Daniel Barclay (Drill) >Assignee: Parth Chandra > Fix For: 1.0.0 > > Attachments: DRILL-2570.1.patch.txt, ElementTraversal.rtf, > xerces-error.rtf > > > [Transcribed from other medium:] > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > - - - - - - - - - - - > When starting Spotfire Server using JDBC driver an error see attachment > (xerces-error) is produced. > This error is then resolved by adding the jars/3rdparty/xercesImpl-2.11.0.jar > from the drillbit package to the classpath for the JDBC client driver. > Then the following error is observed. See attachment (ElementTraversal). > This requires to add jars/3rdparty/xml-apis-1.4.01.jar to the classpath from > the drillbit package. > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > - - - - - - - - - - - > The issue is Tomcat and Spotfire Server does not show any errors and starts > up fine without the Drill JDBC driver. Once the Drill driver is added the > application server fails to start with the errors shown. > Adding the 2 jars to the classpath then resolves the issue. > I have not looked at all the JDBC driver classes, but it is important to note > that the error occurs when the JDBC driver is added and resolved by adding 2 > jars from the drillbit package. > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > - - - - - - - - - - - > > I do not see Drill classes in the stack trace. This seems to be a Tomcat > > configuration issue. > I suspect another possibility: that the Drill JDBC-all Jar file contains a > stray reference to the unfound class (SAXParserFactoryImpl) in some file in > META-INF/services (left over from some package whose classes we either > excluded or renamed (with "shading") > Xxx, Yyy: Can you try this?: > (Temporarily) removing the added XML Jar files from the class path to > re-confirm the problem. > Move the Drill JDBC-all Jar file to be last on the class path (and remove > ). > Report whether the symptoms change. > Thanks. > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > - - - - - - - - - - - -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DRILL-3001) Some functional tests fail when new text reader is disabled
[
https://issues.apache.org/jira/browse/DRILL-3001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14535901#comment-14535901
]
Khurram Faraaz commented on DRILL-3001:
---
No investigation is required for now by dev, I am re-running tests with some
more config options set for the regression run. Thanks.
> Some functional tests fail when new text reader is disabled
> ---
>
> Key: DRILL-3001
> URL: https://issues.apache.org/jira/browse/DRILL-3001
> Project: Apache Drill
> Issue Type: Bug
> Components: Storage - Text & CSV
>Affects Versions: 1.0.0
>Reporter: Khurram Faraaz
>Assignee: Steven Phillips
>
> I am seeing several tests fail in Functional/Passing suite, when I disable
> the new text reader. Some those failures are listed here.
> {code}
> alter system set `exec.storage.enable_new_text_reader` = false;
> +++
> | ok | summary |
> +++
> | true | exec.storage.enable_new_text_reader updated. |
> +++
> 1 row selected (1.442 seconds)
> {code}
> {code}
> running test
> /root/private-sql-hadoop-test/framework/resources/Functional/Passing/data-shapes/wide-columns/5000/1000rows/parquet/q219.q
> 1463647375
> Query failed:
> org.apache.drill.common.exceptions.UserRemoteException: SYSTEM ERROR: null
> Fragment 5:1
> [Error Id: 48e103c5-0c5f-4d60-832c-ef41dc642fd3 on atsqa6c85.qa.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:339)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:324)
> at
> io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:103)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:339)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:324)
> at
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:242)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:339)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:324)
> at
> io.netty.channel.ChannelInboundHandlerAdapter.channelRead(ChannelInboundHandlerAdapter.java:86)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:339)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:324)
> at
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:847)
> at
> io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:131)
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:511)
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:468)
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:382)
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:354)
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:111)
> at java.lang.Thread.run(Thread.java:744)
> {code}
> Another test also fails with the same stack trace
> {code}
> Completed test
> /root/private-sql-hadoop-test/framework/resources/Functional/Passing/json_kvgenflatten/convert/convert_json_text1.q.
> Status PASS
> Query failed:
> org.apache.drill.common.exceptions.UserRemoteException: SYSTEM ERROR: null
> Fragment 0:0
> [Error Id: c9747707-8071-410e-84da-5a0aaec3f77b on atsqa6c87.qa.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.apach
[jira] [Commented] (DRILL-2989) TPCDS Query corrupts Drillbits and causing subsequent unrelated queries to hang (and timeout)
[ https://issues.apache.org/jira/browse/DRILL-2989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14535900#comment-14535900 ] Jacques Nadeau commented on DRILL-2989: --- Please post the information in public, not a private location. > TPCDS Query corrupts Drillbits and causing subsequent unrelated queries to > hang (and timeout) > - > > Key: DRILL-2989 > URL: https://issues.apache.org/jira/browse/DRILL-2989 > Project: Apache Drill > Issue Type: Bug >Affects Versions: 1.0.0 > Environment: RHEL 6.4 >Reporter: Kunal Khatua >Priority: Critical > Fix For: 1.0.0 > > Attachments: dBit_TPC-DBug.jstack.out > > > 30-node setup has TPC-H Drill (SF100) and TPC-DS Drill (SF100) in two > different workspaces. > TPC-H Query 6 is executed on the cluster successfully, followed by execution > of TPC-DS Query 2; which hangs during the executeQuery() operation. After a > 2min timeout, the TPC-H Query is executed on the cluster, but this also hangs > during the fetching of rows from the ResultSet. The profile page for the > second attempt at TPC-H query 6 shows it as pending. > The TPC-H schema is in its own workspace which exposes the directories as > tables. > The TPC-DS schema is in its own workspace, which has views on top of the > directories containing the actual tables' data. > TPCH-06 > [INFO] Will be using Drillbit on 10.10.120.114 > [QUERYID] 2ab41296-1420-ee4b-2617-849b63eb11b4 > [STAT] TOTAL TIME : 7420 msec > TPCDS-02 > [INFO] Will be using Drillbit on 10.10.120.117 > [TIME OUT] Query took more than 120 sec. > TPCH-06 > [INFO] Will be using Drillbit on 10.10.120.130 > [TIME OUT] Query took more than 120 sec. > [QUERYID] 2ab41027-abcc-c48a-7e3c-957bb069f452 > [STAT] TOTAL TIME : 120017 msec -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DRILL-2989) TPCDS Query corrupts Drillbits and causing subsequent unrelated queries to hang (and timeout)
[ https://issues.apache.org/jira/browse/DRILL-2989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14535896#comment-14535896 ] Kunal Khatua commented on DRILL-2989: - Added hung JDBC Client App's JStack as well. The JDBC Client communicated with the foreman on ucs-node6 (out of all the 30 nodes ranging from ucs-node2 to node31) The DRILL-2989.out is the client's output log. We see that the query timed out when attempting to fetch rows for the TPCDS query. After that...the Drillbits are rendered unusable. > TPCDS Query corrupts Drillbits and causing subsequent unrelated queries to > hang (and timeout) > - > > Key: DRILL-2989 > URL: https://issues.apache.org/jira/browse/DRILL-2989 > Project: Apache Drill > Issue Type: Bug >Affects Versions: 1.0.0 > Environment: RHEL 6.4 >Reporter: Kunal Khatua >Priority: Critical > Fix For: 1.0.0 > > Attachments: dBit_TPC-DBug.jstack.out > > > 30-node setup has TPC-H Drill (SF100) and TPC-DS Drill (SF100) in two > different workspaces. > TPC-H Query 6 is executed on the cluster successfully, followed by execution > of TPC-DS Query 2; which hangs during the executeQuery() operation. After a > 2min timeout, the TPC-H Query is executed on the cluster, but this also hangs > during the fetching of rows from the ResultSet. The profile page for the > second attempt at TPC-H query 6 shows it as pending. > The TPC-H schema is in its own workspace which exposes the directories as > tables. > The TPC-DS schema is in its own workspace, which has views on top of the > directories containing the actual tables' data. > TPCH-06 > [INFO] Will be using Drillbit on 10.10.120.114 > [QUERYID] 2ab41296-1420-ee4b-2617-849b63eb11b4 > [STAT] TOTAL TIME : 7420 msec > TPCDS-02 > [INFO] Will be using Drillbit on 10.10.120.117 > [TIME OUT] Query took more than 120 sec. > TPCH-06 > [INFO] Will be using Drillbit on 10.10.120.130 > [TIME OUT] Query took more than 120 sec. > [QUERYID] 2ab41027-abcc-c48a-7e3c-957bb069f452 > [STAT] TOTAL TIME : 120017 msec -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (DRILL-3001) Some functional tests fail when new text reader is disabled
Khurram Faraaz created DRILL-3001:
-
Summary: Some functional tests fail when new text reader is
disabled
Key: DRILL-3001
URL: https://issues.apache.org/jira/browse/DRILL-3001
Project: Apache Drill
Issue Type: Bug
Components: Storage - Text & CSV
Affects Versions: 1.0.0
Reporter: Khurram Faraaz
Assignee: Steven Phillips
I am seeing several tests fail in Functional/Passing suite, when I disable the
new text reader. Some those failures are listed here.
{code}
alter system set `exec.storage.enable_new_text_reader` = false;
+++
| ok | summary |
+++
| true | exec.storage.enable_new_text_reader updated. |
+++
1 row selected (1.442 seconds)
{code}
{code}
running test
/root/private-sql-hadoop-test/framework/resources/Functional/Passing/data-shapes/wide-columns/5000/1000rows/parquet/q219.q
1463647375
Query failed:
org.apache.drill.common.exceptions.UserRemoteException: SYSTEM ERROR: null
Fragment 5:1
[Error Id: 48e103c5-0c5f-4d60-832c-ef41dc642fd3 on atsqa6c85.qa.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:339)
at
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:324)
at
io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:103)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:339)
at
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:324)
at
io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:242)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:339)
at
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:324)
at
io.netty.channel.ChannelInboundHandlerAdapter.channelRead(ChannelInboundHandlerAdapter.java:86)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:339)
at
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:324)
at
io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:847)
at
io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:131)
at
io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:511)
at
io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:468)
at
io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:382)
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:354)
at
io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:111)
at java.lang.Thread.run(Thread.java:744)
{code}
Another test also fails with the same stack trace
{code}
Completed test
/root/private-sql-hadoop-test/framework/resources/Functional/Passing/json_kvgenflatten/convert/convert_json_text1.q.
Status PASS
Query failed:
org.apache.drill.common.exceptions.UserRemoteException: SYSTEM ERROR: null
Fragment 0:0
[Error Id: c9747707-8071-410e-84da-5a0aaec3f77b on atsqa6c87.qa.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.MessageToMe
[jira] [Commented] (DRILL-2941) Update RPC layer to avoid writing local data messages to socket
[ https://issues.apache.org/jira/browse/DRILL-2941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14535878#comment-14535878 ] Jacques Nadeau commented on DRILL-2941: --- Assigning to Steven for review. > Update RPC layer to avoid writing local data messages to socket > --- > > Key: DRILL-2941 > URL: https://issues.apache.org/jira/browse/DRILL-2941 > Project: Apache Drill > Issue Type: Bug > Components: Execution - RPC >Reporter: Jacques Nadeau >Assignee: Steven Phillips > Fix For: 1.0.0 > > Attachments: DRILL-2941.patch > > > Right now, if we send a fragment record batch to localhost, we still traverse > the RPC layer. We should short-circuit this path. This is especially > important in light of the mux and demux exchanges. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-2941) Update RPC layer to avoid writing local data messages to socket
[ https://issues.apache.org/jira/browse/DRILL-2941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Nadeau updated DRILL-2941: -- Assignee: Steven Phillips (was: Jacques Nadeau) > Update RPC layer to avoid writing local data messages to socket > --- > > Key: DRILL-2941 > URL: https://issues.apache.org/jira/browse/DRILL-2941 > Project: Apache Drill > Issue Type: Bug > Components: Execution - RPC >Reporter: Jacques Nadeau >Assignee: Steven Phillips > Fix For: 1.0.0 > > Attachments: DRILL-2941.patch > > > Right now, if we send a fragment record batch to localhost, we still traverse > the RPC layer. We should short-circuit this path. This is especially > important in light of the mux and demux exchanges. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-2003) bootstrap-storage-plugins.json is not merged properly
[ https://issues.apache.org/jira/browse/DRILL-2003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Altekruse updated DRILL-2003: --- Fix Version/s: (was: 1.0.0) 1.1.0 > bootstrap-storage-plugins.json is not merged properly > - > > Key: DRILL-2003 > URL: https://issues.apache.org/jira/browse/DRILL-2003 > Project: Apache Drill > Issue Type: Bug > Components: Metadata >Affects Versions: 0.7.0 >Reporter: Rahul Challapalli >Assignee: Jason Altekruse > Fix For: 1.1.0 > > > Drill not picking up the bootstrap-storage-plugins.json from the conf > directory. I made sure that the Zookeeper's drill directory is empty and the > conf directory is in the classpath. > It looks like there is an issue with the merge with the same file in the jar > file provided with drill. > This worked with 0.6.0 but seems to be broken with the current 0.7.0 release -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DRILL-2897) Update Limit 0 to avoid parallelization
[ https://issues.apache.org/jira/browse/DRILL-2897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14535804#comment-14535804 ] Aman Sinha commented on DRILL-2897: --- Another thing to note is that although tools such as Tableau add LIMIT 0 to a query, it typically won't be disabling hash join; so it is unlikely to encounter the cannot plan exception. > Update Limit 0 to avoid parallelization > --- > > Key: DRILL-2897 > URL: https://issues.apache.org/jira/browse/DRILL-2897 > Project: Apache Drill > Issue Type: Bug >Reporter: Jacques Nadeau >Assignee: Jacques Nadeau > Fix For: 1.0.0 > > Attachments: DRILL-2897.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-2897) Update Limit 0 to avoid parallelization
[ https://issues.apache.org/jira/browse/DRILL-2897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aman Sinha updated DRILL-2897: -- Assignee: Jacques Nadeau (was: Aman Sinha) > Update Limit 0 to avoid parallelization > --- > > Key: DRILL-2897 > URL: https://issues.apache.org/jira/browse/DRILL-2897 > Project: Apache Drill > Issue Type: Bug >Reporter: Jacques Nadeau >Assignee: Jacques Nadeau > Fix For: 1.0.0 > > Attachments: DRILL-2897.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-1315) Allow specifying Zookeeper root znode and cluster-id as JDBC parameters
[
https://issues.apache.org/jira/browse/DRILL-1315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Victoria Markman updated DRILL-1315:
Fix Version/s: (was: 1.0.0)
1.1.0
> Allow specifying Zookeeper root znode and cluster-id as JDBC parameters
> ---
>
> Key: DRILL-1315
> URL: https://issues.apache.org/jira/browse/DRILL-1315
> Project: Apache Drill
> Issue Type: Bug
> Components: Client - JDBC
>Affects Versions: 0.5.0
>Reporter: Aditya Kishore
>Assignee: Parth Chandra
> Fix For: 1.1.0
>
>
> Currently there is no way to specify a different root z-node and cluster-id
> to the Drill JDBC driver and it always attempt to connect to the default
> values (unless there is a {{drill-override.conf}} with the correct values
> also included early in the classpath).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (DRILL-2849) Difference in query results over CSV file created by CTAS, compared to results over original CSV file
[
https://issues.apache.org/jira/browse/DRILL-2849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Victoria Markman resolved DRILL-2849.
-
Resolution: Fixed
> Difference in query results over CSV file created by CTAS, compared to
> results over original CSV file
> --
>
> Key: DRILL-2849
> URL: https://issues.apache.org/jira/browse/DRILL-2849
> Project: Apache Drill
> Issue Type: Bug
> Components: Storage - Text & CSV
>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: Khurram Faraaz
>Priority: Critical
> Fix For: 1.0.0
>
>
> Different results are seen for the same query over CSV data file and another
> CSV data file created by CTAS using the same CSV file.
> Tests were executed on 4 node cluster on CentOS.
> I got rid of the header information that is written by CTAS into the new CSV
> file that CTAS creates, and then ran my queries over CTAS' CSV file.
> query over uncompressed CSV file, deletions/deletions-0-of-00020.csv
> {code}
> > select count(cast(columns[0] as double)),max(cast(columns[0] as
> > double)),min(cast(columns[0] as double)),avg(cast(columns[0] as double)),
> > columns[7] from `deletions/deletions-0-of-00020.csv` group by
> > columns[7];
> 88 rows selected (6.893 seconds)
> =
> {code}
> query over CSV file that was created by CTAS. (input to CTAS was
> deletions/deletions-0-of-00020.csv)
> Notice there is one more record returned.
> {code}
> > select count(cast(columns[0] as double)),max(cast(columns[0] as
> > double)),min(cast(columns[0] as double)),avg(cast(columns[0] as double)),
> > columns[7] from `csvToCSV_0_of_00020/0_0_0.csv` group by columns[7];
>
> 89 rows selected (6.623 seconds)
> ==
> {code}
> query over compressed CSV file
> {code}
> > select count(cast(columns[0] as double)),max(cast(columns[0] as
> > double)),min(cast(columns[0] as double)),avg(cast(columns[0] as double)),
> > columns[7] from `deletions-0-of-00020.csv.gz` group by columns[7];
> 88 rows selected (10.526 seconds)
> ==
> {code}
> In the below cases, the count and sum results are different when query is
> executed over CSV file that was created by CTAS. ( this may explain why we
> see the difference in results in the above queries ? )
> {code}
> 0: jdbc:drill:> select count(cast(columns[0] as double)),max(cast(columns[0]
> as double)),min(cast(columns[0] as double)),avg(cast(columns[0] as double)),
> columns[7] from `deletions/deletions-0-of-00020.csv` where columns[7] is
> null group by columns[7];
> ++++++
> | EXPR$0 | EXPR$1 | EXPR$2 | EXPR$3 | EXPR$4 |
> ++++++
> | 252| 1.362983396001E12 | 1.165768779027E12 | 1.293794515595635E12 |
> null |
> ++++++
> 1 row selected (6.013 seconds)
> 0: jdbc:drill:> select count(cast(columns[0] as double)),max(cast(columns[0]
> as double)),min(cast(columns[0] as double)),avg(cast(columns[0] as double)),
> columns[7] from `deletions-0-of-00020.csv.gz` where columns[7] is null
> group by columns[7];
> ++++++
> | EXPR$0 | EXPR$1 | EXPR$2 | EXPR$3 | EXPR$4 |
> ++++++
> | 252| 1.362983396001E12 | 1.165768779027E12 | 1.293794515595635E12 |
> null |
> ++++++
> 1 row selected (8.899 seconds)
> {code}
> Notice that count and sum results are different (from those above) when query
> is executed over the CSV file created by CTAS.
> {code}
> 0: jdbc:drill:> select count(cast(columns[0] as double)),max(cast(columns[0]
> as double)),min(cast(columns[0] as double)),avg(cast(columns[0] as double)),
> columns[7] from `csvToCSV_0_of_00020/0_0_0.csv` where columns[7] is null
> group by columns[7];
> ++++++
> | EXPR$0 | EXPR$1 | EXPR$2 | EXPR$3 | EXPR$4 |
> ++++++
> | 245| 1.349670663E12 | 1.165768779027E12 | 1.2930281335065144E12 |
> null |
> ++++++
> 1 row selected (5.736 seconds)
> {code}
--
This message was sent by
[jira] [Updated] (DRILL-2234) IOOB when streaming aggregate is on the left side of hash join
[ https://issues.apache.org/jira/browse/DRILL-2234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Victoria Markman updated DRILL-2234: Fix Version/s: (was: 1.0.0) 1.1.0 > IOOB when streaming aggregate is on the left side of hash join > -- > > Key: DRILL-2234 > URL: https://issues.apache.org/jira/browse/DRILL-2234 > Project: Apache Drill > Issue Type: Bug > Components: Execution - Relational Operators >Reporter: Mehant Baid >Assignee: Mehant Baid > Fix For: 1.1.0 > > > This issue is similar to DRILL-2107. > Issue can be reproduced by enabling SwapJoinRule in DrillRuleSets and running > the following query. > alter session set `planner.slice_target` = 1; > alter session set `planner.enable_hashagg` = false; > alter session set `planner.enable_streamagg` = true; > select l_suppkey, sum(l_extendedprice)/sum(l_quantity) as avg_price > from cp.`tpch/lineitem.parquet` where l_orderkey in > (select o_orderkey from cp.`tpch/orders.parquet` where o_custkey = 2) > group by l_suppkey having sum(l_extendedprice)/sum(l_quantity) > 1850.0; -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-2343) Create JDBC tracing proxy driver.
[ https://issues.apache.org/jira/browse/DRILL-2343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Barclay (Drill) updated DRILL-2343: -- Attachment: DRILL-2343.4.patch.txt > Create JDBC tracing proxy driver. > - > > Key: DRILL-2343 > URL: https://issues.apache.org/jira/browse/DRILL-2343 > Project: Apache Drill > Issue Type: New Feature > Components: Client - JDBC >Reporter: Daniel Barclay (Drill) >Assignee: Daniel Barclay (Drill) > Fix For: Future > > Attachments: DRILL-2343.4.patch.txt > > > Create JDBC driver that functions as proxy to Drill (or other) JDBC driver in > order to report calls made across the JDBC API. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-2732) Different logical plan based on field names
[
https://issues.apache.org/jira/browse/DRILL-2732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Victoria Markman updated DRILL-2732:
Fix Version/s: (was: 1.0.0)
1.1.0
> Different logical plan based on field names
> ---
>
> Key: DRILL-2732
> URL: https://issues.apache.org/jira/browse/DRILL-2732
> Project: Apache Drill
> Issue Type: Bug
> Components: Query Planning & Optimization
>Affects Versions: 0.8.0
>Reporter: Adam Gilmore
>Assignee: Jinfeng Ni
> Fix For: 1.1.0
>
>
> The following two queries produce different logical plans:
> {code}
> select count(*) from cp.`employee.json` where mytestFieldNum = 4 and
> myOtherLongIdString = '12345'
> {code}
> {code}
> select count(*) from cp.`employee.json` where my_testFieldNum = 4 and
> my_OtherLongIdString = '12345'
> {code}
> The latter adds a project step to the logical plan. The ramifications of
> this means that, for example, the Mongo storage provider will not push down
> filters because it's matching on a scan/filter.
> It has nothing to do with the underscore - in fact, it seems if you
> substitute the underscore with a variety of characters, it produces different
> results.
> It also seems to not be reliant on the length of the field names in question.
> These two queries should really produce identical logical plans.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DRILL-2838) Applying flatten after joining 2 sub-queries returns empty maps
[
https://issues.apache.org/jira/browse/DRILL-2838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Victoria Markman updated DRILL-2838:
Fix Version/s: (was: 1.0.0)
1.1.0
> Applying flatten after joining 2 sub-queries returns empty maps
> ---
>
> Key: DRILL-2838
> URL: https://issues.apache.org/jira/browse/DRILL-2838
> Project: Apache Drill
> Issue Type: Bug
> Components: Execution - Relational Operators
>Reporter: Rahul Challapalli
>Assignee: Jason Altekruse
>Priority: Critical
> Fix For: 1.1.0
>
> Attachments: data.json
>
>
> git.commit.id.abbrev=5cd36c5
> The below query applies flatten after joining 2 subqueries. It generates
> empty maps which is wrong
> {code}
> select v1.uid, flatten(events), flatten(transactions) from
> (select uid, events from `data.json`) v1
> inner join
> (select uid, transactions from `data.json`) v2
> on v1.uid = v2.uid;
> ++++
> |uid | EXPR$1 | EXPR$2 |
> ++++
> | 1 | {} | {} |
> | 1 | {} | {} |
> | 1 | {} | {} |
> | 1 | {} | {} |
> | 1 | {} | {} |
> | 1 | {} | {} |
> | 1 | {} | {} |
> | 1 | {} | {} |
> | 1 | {} | {} |
> | 1 | {} | {} |
> | 1 | {} | {} |
> | 1 | {} | {} |
> | 1 | {} | {} |
> | 1 | {} | {} |
> | 1 | {} | {} |
> | 1 | {} | {} |
> | 1 | {} | {} |
> | 1 | {} | {} |
> | 2 | {} | {} |
> | 2 | {} | {} |
> | 2 | {} | {} |
> | 2 | {} | {} |
> | 2 | {} | {} |
> | 2 | {} | {} |
> | 2 | {} | {} |
> | 2 | {} | {} |
> | 2 | {} | {} |
> | 2 | {} | {} |
> | 2 | {} | {} |
> | 2 | {} | {} |
> | 2 | {} | {} |
> | 2 | {} | {} |
> | 2 | {} | {} |
> | 2 | {} | {} |
> | 2 | {} | {} |
> | 2 | {} | {} |
> ++++
> 36 rows selected (0.244 seconds)
> {code}
> I attached the data set. Let me know if you have any questions.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DRILL-2100) Drill not deleting spooling files
[ https://issues.apache.org/jira/browse/DRILL-2100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Victoria Markman updated DRILL-2100: Fix Version/s: (was: 1.0.0) 1.1.0 > Drill not deleting spooling files > - > > Key: DRILL-2100 > URL: https://issues.apache.org/jira/browse/DRILL-2100 > Project: Apache Drill > Issue Type: Bug > Components: Execution - Relational Operators >Affects Versions: 0.8.0 >Reporter: Abhishek Girish >Assignee: Steven Phillips > Fix For: 1.1.0 > > > Currently, after forcing queries to use an external sort by switching off > hash join/agg causes spill-to-disk files accumulating. > This causes issues with disk space availability when the spill is configured > to be on the local file system (/tmp/drill). Also not optimal when configured > to use DFS (custom). > Drill must clean up all temporary files created after a query completes or > after a drillbit restart. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-2774) Updated drill-patch-review.py to use git-format-patch
[ https://issues.apache.org/jira/browse/DRILL-2774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Victoria Markman updated DRILL-2774: Fix Version/s: (was: 1.0.0) 1.1.0 > Updated drill-patch-review.py to use git-format-patch > - > > Key: DRILL-2774 > URL: https://issues.apache.org/jira/browse/DRILL-2774 > Project: Apache Drill > Issue Type: Bug > Components: Tools, Build & Test >Reporter: Steven Phillips >Assignee: Steven Phillips >Priority: Minor > Fix For: 1.1.0 > > Attachments: DRILL-2774.patch, DRILL-2774.patch > > > The tool currently uses git diff to generate the patches, which does not > preserve commit information, and which is required for submitting patches in > the Drill community. > This doesn't work properly when there are multiple commits, so as part of > this change, we enforce the requirement that the branch used to create the > patch is exactly one commit ahead and zero behind the remote branch. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[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
]
Victoria Markman updated DRILL-2516:
Fix Version/s: (was: 1.0.0)
1.1.0
> 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.1.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(AbstractRecordBatc
[jira] [Updated] (DRILL-2343) Create JDBC tracing proxy driver.
[ https://issues.apache.org/jira/browse/DRILL-2343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Barclay (Drill) updated DRILL-2343: -- Attachment: (was: DRILL-2343.3.patch.txt) > Create JDBC tracing proxy driver. > - > > Key: DRILL-2343 > URL: https://issues.apache.org/jira/browse/DRILL-2343 > Project: Apache Drill > Issue Type: New Feature > Components: Client - JDBC >Reporter: Daniel Barclay (Drill) >Assignee: Daniel Barclay (Drill) > Fix For: Future > > Attachments: DRILL-2343.4.patch.txt > > > Create JDBC driver that functions as proxy to Drill (or other) JDBC driver in > order to report calls made across the JDBC API. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (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
]
Victoria Markman updated DRILL-2167:
Fix Version/s: (was: 1.0.0)
1.1.0
> 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.1.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] [Updated] (DRILL-2310) Drill fails to start in embedded mode on windows
[ https://issues.apache.org/jira/browse/DRILL-2310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Victoria Markman updated DRILL-2310: Assignee: Aditya Kishore (was: Steven Phillips) > Drill fails to start in embedded mode on windows > > > Key: DRILL-2310 > URL: https://issues.apache.org/jira/browse/DRILL-2310 > Project: Apache Drill > Issue Type: Bug > Components: Tools, Build & Test >Affects Versions: 0.8.0 >Reporter: Krystal >Assignee: Aditya Kishore > Fix For: 1.0.0 > > > git.commit.id.abbrev=c8d2fe1 > I installed it on windows 7 > I invoked sqlline in embedded mode via: > C:\drill\apache-drill-0.8.0-SNAPSHOT\bin>sqlline.bat -u "jdbc:drill:zk=local" > I got the following error: > Error: Failure while attempting to start Drillbit in embedded mode. > (state=,code=0) > With debug turned on, the following error is displayed: > 15:36:53.608 [main] WARN org.apache.hadoop.fs.FSInputChecker - Problem > opening checksum file: /tmp/drill/sys.storage_ > ugins/hbase.sys.drill. Ignoring exception: > java.io.EOFException: null > at java.io.DataInputStream.readFully(Unknown Source) ~[na:1.7.0_10] > at java.io.DataInputStream.readFully(Unknown Source) ~[na:1.7.0_10] > at > org.apache.hadoop.fs.ChecksumFileSystem$ChecksumFSInputChecker.(ChecksumFileSystem.java:146) > ~[hadoop > ommon-2.4.1.jar:na] > at > org.apache.hadoop.fs.ChecksumFileSystem.open(ChecksumFileSystem.java:339) > [hadoop-common-2.4.1.jar:na] > at org.apache.hadoop.fs.FileSystem.open(FileSystem.java:764) > [hadoop-common-2.4.1.jar:na] > at > org.apache.drill.exec.store.dfs.DrillFileSystem.open(DrillFileSystem.java:145) > [drill-java-exec-0.8.0-SNAPS > T-rebuffed.jar:0.8.0-SNAPSHOT] > at > org.apache.drill.exec.store.sys.local.FilePStore.get(FilePStore.java:136) > [drill-java-exec-0.8.0-SNAPSHOT-r > uffed.jar:0.8.0-SNAPSHOT] > at > org.apache.drill.exec.store.sys.local.FilePStore$Iter$DeferredEntry.getValue(FilePStore.java:218) > [drill-ja > -exec-0.8.0-SNAPSHOT-rebuffed.jar:0.8.0-SNAPSHOT] > at > org.apache.drill.exec.store.StoragePluginRegistry.createPlugins(StoragePluginRegistry.java:166) > [drill-java > xec-0.8.0-SNAPSHOT-rebuffed.jar:0.8.0-SNAPSHOT] > at > org.apache.drill.exec.store.StoragePluginRegistry.init(StoragePluginRegistry.java:130) > [drill-java-exec-0.8 > -SNAPSHOT-rebuffed.jar:0.8.0-SNAPSHOT] > at org.apache.drill.exec.server.Drillbit.run(Drillbit.java:155) > [drill-java-exec-0.8.0-SNAPSHOT-rebuffed.jar:0 > .0-SNAPSHOT] > at > org.apache.drill.jdbc.DrillConnectionImpl.(DrillConnectionImpl.java:79) > [drill-jdbc-0.8.0-SNAPSHOT.ja > 0.8.0-SNAPSHOT] > at > org.apache.drill.jdbc.DrillJdbc41Factory$DrillJdbc41Connection.(DrillJdbc41Factory.java:94) > [drill-jd > -0.8.0-SNAPSHOT.jar:0.8.0-SNAPSHOT] > at > org.apache.drill.jdbc.DrillJdbc41Factory.newDrillConnection(DrillJdbc41Factory.java:57) > [drill-jdbc-0.8.0-S > PSHOT.jar:0.8.0-SNAPSHOT] > at > org.apache.drill.jdbc.DrillJdbc41Factory.newDrillConnection(DrillJdbc41Factory.java:43) > [drill-jdbc-0.8.0-S > PSHOT.jar:0.8.0-SNAPSHOT] > at > org.apache.drill.jdbc.DrillFactory.newConnection(DrillFactory.java:54) > [drill-jdbc-0.8.0-SNAPSHOT.jar:0.8.0 > NAPSHOT] > at > net.hydromatic.avatica.UnregisteredDriver.connect(UnregisteredDriver.java:126) > [optiq-avatica-0.9-drill-r20 > ar:na] > at sqlline.SqlLine$DatabaseConnection.connect(SqlLine.java:4732) > [sqlline-1.1.6.jar:na] > at > sqlline.SqlLine$DatabaseConnection.getConnection(SqlLine.java:4786) > [sqlline-1.1.6.jar:na] > at sqlline.SqlLine$Commands.connect(SqlLine.java:4026) > [sqlline-1.1.6.jar:na] > at sqlline.SqlLine$Commands.connect(SqlLine.java:3935) > [sqlline-1.1.6.jar:na] > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > ~[na:1.7.0_10] > at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) > ~[na:1.7.0_10] > at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) > ~[na:1.7.0_10] > at java.lang.reflect.Method.invoke(Unknown Source) ~[na:1.7.0_10] > at > sqlline.SqlLine$ReflectiveCommandHandler.execute(SqlLine.java:2884) > [sqlline-1.1.6.jar:na] > at sqlline.SqlLine.dispatch(SqlLine.java:885) [sqlline-1.1.6.jar:na] > at sqlline.SqlLine.initArgs(SqlLine.java:693) [sqlline-1.1.6.jar:na] > at sqlline.SqlLine.begin(SqlLine.java:745) [sqlline-1.1.6.jar:na] > at sqlline.SqlLine.start(SqlLine.java:498) [sqlline-1.1.6.jar:na] > at sqlline.SqlLine.main(SqlLine.java:460) [sqlline-1.1.6.jar:na] > Drill successfully created the /tmp/drill/sys.storage_ > ugins/hbase.sys.drill file so not sure why it can't ac
[jira] [Updated] (DRILL-2974) Make OutOfMemoryException an unchecked exception and remove OutOfMemoryRuntimeException
[ https://issues.apache.org/jira/browse/DRILL-2974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Victoria Markman updated DRILL-2974: Fix Version/s: (was: 1.0.0) 1.1.0 > Make OutOfMemoryException an unchecked exception and remove > OutOfMemoryRuntimeException > --- > > Key: DRILL-2974 > URL: https://issues.apache.org/jira/browse/DRILL-2974 > Project: Apache Drill > Issue Type: Improvement > Components: Execution - Flow >Reporter: Deneche A. Hakim >Assignee: Sudheesh Katkam > Fix For: 1.1.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-2915) Regression: Mondrian query5614.q - Query failed: SYSTEM ERROR: This query cannot be planned possibly due to either a cartesian join or an inequality join
[
https://issues.apache.org/jira/browse/DRILL-2915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Victoria Markman updated DRILL-2915:
Fix Version/s: (was: 1.0.0)
1.1.0
> Regression: Mondrian query5614.q - Query failed: SYSTEM ERROR: This query
> cannot be planned possibly due to either a cartesian join or an inequality
> join
> -
>
> Key: DRILL-2915
> URL: https://issues.apache.org/jira/browse/DRILL-2915
> Project: Apache Drill
> Issue Type: Bug
> Components: Query Planning & Optimization
>Affects Versions: 0.9.0
>Reporter: Chun Chang
>Assignee: Aman Sinha
>Priority: Critical
> Fix For: 1.1.0
>
> Attachments: mondrian_query5614.explain
>
>
> #Wed Apr 29 14:39:22 EDT 2015
> git.commit.id.abbrev=f5b0f49
> The following mondrian query fails now.
> {code}
> SELECT store.store_state AS c0,
>Count(DISTINCT sales_fact_1997.customer_id) AS m0
> FROM store AS store,
>sales_fact_1997 AS sales_fact_1997,
>time_by_day AS time_by_day,
>product_class AS product_class,
>product AS product
> WHERE sales_fact_1997.store_id = store.store_id
>AND store.store_state = 'CA'
>AND sales_fact_1997.time_id = time_by_day.time_id
>AND sales_fact_1997.product_id = product.product_id
>AND product.product_class_id = product_class.product_class_id
>AND ( ( product_class.product_family = 'Food'
>AND time_by_day.quarter = 'Q1'
>AND time_by_day.the_year = 1997 )
> OR ( product_class.product_family = 'Drink'
>AND time_by_day.month_of_year = 4
>AND time_by_day.quarter = 'Q2'
>AND time_by_day.the_year = 1997 ) )
> GROUP BY store.store_state;
> {code}
> postgres:
> {code}
> foodmart=# select store.store_state as c0, count(distinct
> sales_fact_1997.customer_id) as m0 from store as store, sales_fact_1997 as
> sales_fact_1997, time_by_day as time_by_day, product_class as product_class,
> product as product where sales_fact_1997.store_id = store.store_id and
> store.store_state = 'CA' and sales_fact_1997.time_id = time_by_day.time_id
> and sales_fact_1997.product_id = product.product_id and
> product.product_class_id = product_class.product_class_id and
> ((product_class.product_family = 'Food' and time_by_day.quarter = 'Q1' and
> time_by_day.the_year = 1997) or (product_class.product_family = 'Drink' and
> time_by_day.month_of_year = 4 and time_by_day.quarter = 'Q2' and
> time_by_day.the_year = 1997)) group by store.store_state;
> c0 | m0
> +--
> CA | 1175
> (1 row)
> {code}
> drill failed
> {code}
> 0: jdbc:drill:schema=dfs.drillTestDirAdvanced> select store.store_state as
> c0, count(distinct sales_fact_1997.customer_id) as m0 from store as store,
> sales_fact_1997 as sales_fact_1997, time_by_day as time_by_day, product_class
> as product_class, product as product where sales_fact_1997.store_id =
> store.store_id and store.store_state = 'CA' and sales_fact_1997.time_id =
> time_by_day.time_id and sales_fact_1997.product_id = product.product_id and
> product.product_class_id = product_class.product_class_id and
> ((product_class.product_family = 'Food' and time_by_day.quarter = 'Q1' and
> time_by_day.the_year = 1997) or (product_class.product_family = 'Drink' and
> time_by_day.month_of_year = 4 and time_by_day.quarter = 'Q2' and
> time_by_day.the_year = 1997)) group by store.store_state;
> Query failed: SYSTEM ERROR: This query cannot be planned possibly due to
> either a cartesian join or an inequality join
> [3eb99963-92aa-4129-844f-fe43839537b9 on qa-node119.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] [Updated] (DRILL-1673) Flatten function can not work well with nested arrays.
[
https://issues.apache.org/jira/browse/DRILL-1673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Victoria Markman updated DRILL-1673:
Fix Version/s: (was: 1.0.0)
1.1.0
> Flatten function can not work well with nested arrays.
> --
>
> Key: DRILL-1673
> URL: https://issues.apache.org/jira/browse/DRILL-1673
> Project: Apache Drill
> Issue Type: Bug
> Components: Functions - Drill
>Affects Versions: 0.7.0
> Environment: 0.7.0
>Reporter: Hao Zhu
>Assignee: Jason Altekruse
>Priority: Blocker
> Fix For: 1.1.0
>
> Attachments: DRILL-1673.patch, error.log
>
>
> Flatten function failed to scan nested arrays , for example something like
> ""[[ ]]"".
> The only difference of JSON files between below 2 tests is
> "num":[1,2,3]
> VS
> "num":[[1,2,3]]
> ==Test 1 (Works well):==
> file:
> {code}
> {"fixed_column":"abc", "list_column":[{"id1":"1","name":"zhu", "num":
> [1,2,3]}, {"id1":"2","name":"hao", "num": [4,5,6]} ]}
> {code}
> SQL:
> {code}
> 0: jdbc:drill:zk=local> select t.`fixed_column` as fixed_column,
> flatten(t.`list_column`) from
> dfs.root.`/Users/hzu/Documents/sharefolder/hp/n2.json` as t;
> +--++
> | fixed_column | EXPR$1 |
> +--++
> | abc | {"id1":"1","name":"zhu","num":[1,2,3]} |
> | abc | {"id1":"2","name":"hao","num":[4,5,6]} |
> +--++
> 2 rows selected (0.154 seconds)
> {code}
> ==Test 2 (Failed):==
> file:
> {code}
> {"fixed_column":"abc", "list_column":[{"id1":"1","name":"zhu", "num":
> [[1,2,3]]}, {"id1":"2","name":"hao", "num": [[4,5,6]]} ]}
> {code}
> SQL:
> {code}
> 0: jdbc:drill:zk=local> select t.`fixed_column` as fixed_column,
> flatten(t.`list_column`) from
> dfs.root.`/Users/hzu/Documents/sharefolder/hp/n3.json` as t;
> +--++
> | fixed_column | EXPR$1 |
> +--++
> Query failed: Failure while running fragment.[
> df28347b-fac1-497d-b9c5-a313ba77aa4d on 10.250.0.115:31010 ]
> (java.lang.UnsupportedOperationException)
>
> org.apache.drill.exec.vector.complex.RepeatedListVector$RepeatedListTransferPair.splitAndTransfer():339
>
> org.apache.drill.exec.vector.complex.RepeatedMapVector$SingleMapTransferPair.splitAndTransfer():305
> org.apache.drill.exec.test.generated.FlattenerGen22.flattenRecords():93
>
> org.apache.drill.exec.physical.impl.flatten.FlattenRecordBatch.doWork():152
> org.apache.drill.exec.record.AbstractSingleRecordBatch.innerNext():89
>
> org.apache.drill.exec.physical.impl.flatten.FlattenRecordBatch.innerNext():118
> org.apache.drill.exec.record.AbstractRecordBatch.next():106
>
> org.apache.drill.exec.physical.impl.validate.IteratorValidatorBatchIterator.next():124
> org.apache.drill.exec.record.AbstractRecordBatch.next():86
> org.apache.drill.exec.record.AbstractRecordBatch.next():76
> org.apache.drill.exec.record.AbstractSingleRecordBatch.innerNext():52
>
> org.apache.drill.exec.physical.impl.project.ProjectRecordBatch.innerNext():129
> org.apache.drill.exec.record.AbstractRecordBatch.next():106
>
> org.apache.drill.exec.physical.impl.validate.IteratorValidatorBatchIterator.next():124
> org.apache.drill.exec.physical.impl.BaseRootExec.next():67
>
> org.apache.drill.exec.physical.impl.ScreenCreator$ScreenRoot.innerNext():122
> org.apache.drill.exec.physical.impl.BaseRootExec.next():57
> org.apache.drill.exec.work.fragment.FragmentExecutor.run():105
> org.apache.drill.exec.work.WorkManager$RunnableWrapper.run():249
> ...():0
> 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}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DRILL-2677) Query does not go beyond 4096 lines in small JSON files
[
https://issues.apache.org/jira/browse/DRILL-2677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Victoria Markman updated DRILL-2677:
Fix Version/s: (was: 1.0.0)
1.1.0
> Query does not go beyond 4096 lines in small JSON files
> ---
>
> Key: DRILL-2677
> URL: https://issues.apache.org/jira/browse/DRILL-2677
> Project: Apache Drill
> Issue Type: Bug
> Components: Storage - JSON
> Environment: drill 0.8 official build
>Reporter: Alexander Reshetov
>Assignee: Jason Altekruse
> Fix For: 1.1.0
>
> Attachments: dataset_4095_and_1.json, dataset_4096_and_1.json,
> dataset_sample.json.gz.part-aa, dataset_sample.json.gz.part-ab,
> dataset_sample.json.gz.part-ac, dataset_sample.json.gz.part-ad,
> dataset_sample.json.gz.part-ae, dataset_sample.json.gz.part-af
>
>
> Hello,
> I'm trying to execute next query:
> {code}
> select * from (select source.pck, source.`timestamp`,
> flatten(source.HostUpdateTypeNW.Transfers) as entry from
> dfs.`/mnt/data/dataset_4095_and_1.json` as source) as parsed;
> {code}
> And it works as expected and I got result:
> {code}
> ++++
> |pck | timestamp | entry|
> ++++
> | 3547 | 1419807470286356 |
> {"TransferingPurpose":"8","TransferingImpact":"88","TransferingKind":"8","TransferingTime":"8","PackageOrigSenderID":"8","TransferingID":"8","TransitCN":"888","PackageChkPnt":"","PackageFullSize":"8","TransferingSessionID":"8","SubpackagesCounter":"8"}
> |
> ++++
> 1 row selected (0.188 seconds)
> {code}
> This file contains 4095 same lines of one JSON string + at the end another
> JOSN line (see attached file dataset_4095_and_1.json)
> The problem is when first string repeats more than 4095 times query got
> exception. Here is query for file with 4096 string of first type + 1 string
> of another (see attached file dataset_4096_and_1.json).
> {code}
> select * from (select source.pck, source.`timestamp`,
> flatten(source.HostUpdateTypeNW.Transfers) as entry from
> dfs.`/mnt/data/dataset_4096_and_1.json` as source) as parsed;
> Exception in thread "2ae108ff-b7ea-8f07-054e-84875815d856:frag:0:0"
> java.lang.RuntimeException: Error closing fragment context.
> at
> org.apache.drill.exec.work.fragment.FragmentExecutor.closeOutResources(FragmentExecutor.java:224)
> at
> org.apache.drill.exec.work.fragment.FragmentExecutor.run(FragmentExecutor.java:187)
> 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)
> Caused by: java.lang.ClassCastException:
> org.apache.drill.exec.vector.NullableIntVector cannot be cast to
> org.apache.drill.exec.vector.RepeatedVector
> at
> org.apache.drill.exec.physical.impl.flatten.FlattenRecordBatch.getFlattenFieldTransferPair(FlattenRecordBatch.java:274)
> at
> org.apache.drill.exec.physical.impl.flatten.FlattenRecordBatch.setupNewSchema(FlattenRecordBatch.java:296)
> at
> org.apache.drill.exec.record.AbstractSingleRecordBatch.innerNext(AbstractSingleRecordBatch.java:78)
> at
> org.apache.drill.exec.physical.impl.flatten.FlattenRecordBatch.innerNext(FlattenRecordBatch.java:122)
> at
> org.apache.drill.exec.record.AbstractRecordBatch.next(AbstractRecordBatch.java:142)
> at
> org.apache.drill.exec.physical.impl.validate.IteratorValidatorBatchIterator.next(IteratorValidatorBatchIterator.java:118)
> at
> org.apache.drill.exec.record.AbstractRecordBatch.next(AbstractRecordBatch.java:99)
> at
> org.apache.drill.exec.record.AbstractRecordBatch.next(AbstractRecordBatch.java:89)
> at
> org.apache.drill.exec.record.AbstractSingleRecordBatch.innerNext(AbstractSingleRecordBatch.java:51)
> at
> org.apache.drill.exec.physical.impl.project.ProjectRecordBatch.innerNext(ProjectRecordBatch.java:134)
> at
> org.apache.drill.exec.record.AbstractRecordBatch.next(AbstractRecordBatch.java:142)
> at
> org.apache.drill.exec.physical.impl.validate.IteratorValidatorBatchIterator.next(IteratorValidatorBatchIterator.java:118)
> at
> org.apache.drill.exec.physical.impl.BaseRootExec.next(BaseRootExec.java:68)
> at
> org.apache.drill.exec.physical.impl.ScreenCreator$ScreenRoot.innerNext(ScreenCreator.java:96)
> at
> org.apache.drill.exec.physical.impl.BaseRootExec.next(BaseRootExec.java:58)
> at
> org.apache.drill.exec.work.fragment.FragmentExecutor.run(FragmentExecutor.java:163)
> ... 4 more
[jira] [Updated] (DRILL-2903) Update TestDrillbitResilience tests so that they correctly manage canceled queries that get to complete too quickly.
[ https://issues.apache.org/jira/browse/DRILL-2903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Victoria Markman updated DRILL-2903: Fix Version/s: (was: 1.0.0) 1.1.0 > Update TestDrillbitResilience tests so that they correctly manage canceled > queries that get to complete too quickly. > > > Key: DRILL-2903 > URL: https://issues.apache.org/jira/browse/DRILL-2903 > Project: Apache Drill > Issue Type: Bug > Components: Execution - Flow >Reporter: Jacques Nadeau >Assignee: Sudheesh Katkam >Priority: Critical > Fix For: 1.1.0 > > > Due to timing issues, this test currently appears to flap. We need to update > it so that this isn't an issue and then reenable it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-1942) Improve off-heap memory usage tracking
[ https://issues.apache.org/jira/browse/DRILL-1942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Westin updated DRILL-1942: Attachment: DRILL-1942.2.patch.txt After some jiggery-pokery, I managed to get review board to accept this patch: https://reviews.apache.org/r/34004/ . > Improve off-heap memory usage tracking > -- > > Key: DRILL-1942 > URL: https://issues.apache.org/jira/browse/DRILL-1942 > Project: Apache Drill > Issue Type: Improvement > Components: Execution - Relational Operators >Reporter: Chris Westin >Assignee: Chris Westin > Fix For: 1.0.0 > > Attachments: DRILL-1942.1.patch.txt, DRILL-1942.2.patch.txt > > > We're using a lot more memory than we think we should. We may be leaking it, > or not releasing it as soon as we could. > This is a call to come up with some improved tracking so that we can get > statistics out about exactly where we're using it, and whether or not we can > release it earlier. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-2570) Broken JDBC-All Jar packaging can cause missing XML classes
[ https://issues.apache.org/jira/browse/DRILL-2570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Barclay (Drill) updated DRILL-2570: -- Assignee: Parth Chandra (was: Daniel Barclay (Drill)) > Broken JDBC-All Jar packaging can cause missing XML classes > --- > > Key: DRILL-2570 > URL: https://issues.apache.org/jira/browse/DRILL-2570 > Project: Apache Drill > Issue Type: Bug > Components: Tools, Build & Test >Reporter: Daniel Barclay (Drill) >Assignee: Parth Chandra > Fix For: 1.0.0 > > Attachments: DRILL-2570.1.patch.txt, ElementTraversal.rtf, > xerces-error.rtf > > > [Transcribed from other medium:] > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > - - - - - - - - - - - > When starting Spotfire Server using JDBC driver an error see attachment > (xerces-error) is produced. > This error is then resolved by adding the jars/3rdparty/xercesImpl-2.11.0.jar > from the drillbit package to the classpath for the JDBC client driver. > Then the following error is observed. See attachment (ElementTraversal). > This requires to add jars/3rdparty/xml-apis-1.4.01.jar to the classpath from > the drillbit package. > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > - - - - - - - - - - - > The issue is Tomcat and Spotfire Server does not show any errors and starts > up fine without the Drill JDBC driver. Once the Drill driver is added the > application server fails to start with the errors shown. > Adding the 2 jars to the classpath then resolves the issue. > I have not looked at all the JDBC driver classes, but it is important to note > that the error occurs when the JDBC driver is added and resolved by adding 2 > jars from the drillbit package. > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > - - - - - - - - - - - > > I do not see Drill classes in the stack trace. This seems to be a Tomcat > > configuration issue. > I suspect another possibility: that the Drill JDBC-all Jar file contains a > stray reference to the unfound class (SAXParserFactoryImpl) in some file in > META-INF/services (left over from some package whose classes we either > excluded or renamed (with "shading") > Xxx, Yyy: Can you try this?: > (Temporarily) removing the added XML Jar files from the class path to > re-confirm the problem. > Move the Drill JDBC-all Jar file to be last on the class path (and remove > ). > Report whether the symptoms change. > Thanks. > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > - - - - - - - - - - - -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DRILL-2425) Wrong results when identifier change cases within the same data file
[
https://issues.apache.org/jira/browse/DRILL-2425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14535746#comment-14535746
]
Hanifi Gunes commented on DRILL-2425:
-
[~sphillips] this seems a duplicate of DRILL-2036.
> Wrong results when identifier change cases within the same data file
>
>
> Key: DRILL-2425
> URL: https://issues.apache.org/jira/browse/DRILL-2425
> Project: Apache Drill
> Issue Type: Bug
> Components: Execution - Data Types
>Affects Versions: 0.8.0
>Reporter: Chun Chang
>Assignee: Steven Phillips
>Priority: Critical
> Fix For: 1.0.0
>
>
> #Fri Mar 06 16:51:10 EST 2015
> git.commit.id.abbrev=fb293ba
> I have the following JSON file that one of the identifier change cases:
> {code}
> [root@qa-node120 md-83]# hadoop fs -cat
> /drill/testdata/complex_type/json/schema/a.json
> {"SOURCE": "ebm","msAddressIpv6Array": null}
> {"SOURCE": "ebm","msAddressIpv6Array": {"msAddressIpv6_1":"99.111.222.0",
> "msAddressIpv6_2":"88.222.333.0"}}
> {"SOURCE": "ebm","msAddressIpv6Array": {"msAddressIpv6_1":"99.111.222.1",
> "msAddressIpv6_2":"88.222.333.1"}}
> {"SOURCE": "ebm","msAddressIpv6Array": {"msaddressipv6_1":"99.111.222.2",
> "msAddressIpv6_2":"88.222.333.2"}}
> {code}
> Query this file through drill gives wrong results:
> {code}
> 0: jdbc:drill:schema=dfs.drillTestDirComplexJ> select
> t.msAddressIpv6Array.msAddressIpv6_1 as msAddressIpv6_1 from `schema/a.json`
> t;
> +-+
> | msAddressIpv6_1 |
> +-+
> | null|
> | null|
> | null|
> | 99.111.222.2|
> +-+
> {code}
> plan:
> {code}
> 0: jdbc:drill:schema=dfs.drillTestDirComplexJ> explain plan for select
> t.msAddressIpv6Array.msAddressIpv6_1 as msAddressIpv6_1 from `schema/a.json`
> t;
> +++
> |text|json|
> +++
> | 00-00Screen
> 00-01 Project(msAddressIpv6_1=[ITEM($0, 'msAddressIpv6_1')])
> 00-02Scan(groupscan=[EasyGroupScan
> [selectionRoot=/drill/testdata/complex_type/json/schema/a.json, numFiles=1,
> columns=[`msAddressIpv6Array`.`msAddressIpv6_1`],
> files=[maprfs:/drill/testdata/complex_type/json/schema/a.json]]])
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DRILL-2994) Incorrect error message when disconnecting from server (using direct connection to drillbit)
[ https://issues.apache.org/jira/browse/DRILL-2994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hanifi Gunes updated DRILL-2994: Assignee: Parth Chandra (was: Hanifi Gunes) > Incorrect error message when disconnecting from server (using direct > connection to drillbit) > > > Key: DRILL-2994 > URL: https://issues.apache.org/jira/browse/DRILL-2994 > Project: Apache Drill > Issue Type: Bug > Components: Client - JDBC >Reporter: Parth Chandra >Assignee: Parth Chandra >Priority: Minor > Fix For: 1.0.0 > > Attachments: DRILL-2994.1.patch.diff > > > If connected to the server using a direct drillbit connection, JDBC client > (sqlline) prints an already disconnected error when disconnecting. > This happens because of an exception because the client is trying to close > the ZK cluster coordinator which is null. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-2425) Wrong results when identifier change cases within the same data file
[
https://issues.apache.org/jira/browse/DRILL-2425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hanifi Gunes updated DRILL-2425:
Assignee: Steven Phillips (was: Hanifi Gunes)
> Wrong results when identifier change cases within the same data file
>
>
> Key: DRILL-2425
> URL: https://issues.apache.org/jira/browse/DRILL-2425
> Project: Apache Drill
> Issue Type: Bug
> Components: Execution - Data Types
>Affects Versions: 0.8.0
>Reporter: Chun Chang
>Assignee: Steven Phillips
>Priority: Critical
> Fix For: 1.0.0
>
>
> #Fri Mar 06 16:51:10 EST 2015
> git.commit.id.abbrev=fb293ba
> I have the following JSON file that one of the identifier change cases:
> {code}
> [root@qa-node120 md-83]# hadoop fs -cat
> /drill/testdata/complex_type/json/schema/a.json
> {"SOURCE": "ebm","msAddressIpv6Array": null}
> {"SOURCE": "ebm","msAddressIpv6Array": {"msAddressIpv6_1":"99.111.222.0",
> "msAddressIpv6_2":"88.222.333.0"}}
> {"SOURCE": "ebm","msAddressIpv6Array": {"msAddressIpv6_1":"99.111.222.1",
> "msAddressIpv6_2":"88.222.333.1"}}
> {"SOURCE": "ebm","msAddressIpv6Array": {"msaddressipv6_1":"99.111.222.2",
> "msAddressIpv6_2":"88.222.333.2"}}
> {code}
> Query this file through drill gives wrong results:
> {code}
> 0: jdbc:drill:schema=dfs.drillTestDirComplexJ> select
> t.msAddressIpv6Array.msAddressIpv6_1 as msAddressIpv6_1 from `schema/a.json`
> t;
> +-+
> | msAddressIpv6_1 |
> +-+
> | null|
> | null|
> | null|
> | 99.111.222.2|
> +-+
> {code}
> plan:
> {code}
> 0: jdbc:drill:schema=dfs.drillTestDirComplexJ> explain plan for select
> t.msAddressIpv6Array.msAddressIpv6_1 as msAddressIpv6_1 from `schema/a.json`
> t;
> +++
> |text|json|
> +++
> | 00-00Screen
> 00-01 Project(msAddressIpv6_1=[ITEM($0, 'msAddressIpv6_1')])
> 00-02Scan(groupscan=[EasyGroupScan
> [selectionRoot=/drill/testdata/complex_type/json/schema/a.json, numFiles=1,
> columns=[`msAddressIpv6Array`.`msAddressIpv6_1`],
> files=[maprfs:/drill/testdata/complex_type/json/schema/a.json]]])
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DRILL-2994) Incorrect error message when disconnecting from server (using direct connection to drillbit)
[ https://issues.apache.org/jira/browse/DRILL-2994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14535729#comment-14535729 ] Hanifi Gunes commented on DRILL-2994: - +1 > Incorrect error message when disconnecting from server (using direct > connection to drillbit) > > > Key: DRILL-2994 > URL: https://issues.apache.org/jira/browse/DRILL-2994 > Project: Apache Drill > Issue Type: Bug > Components: Client - JDBC >Reporter: Parth Chandra >Assignee: Hanifi Gunes >Priority: Minor > Fix For: 1.0.0 > > Attachments: DRILL-2994.1.patch.diff > > > If connected to the server using a direct drillbit connection, JDBC client > (sqlline) prints an already disconnected error when disconnecting. > This happens because of an exception because the client is trying to close > the ZK cluster coordinator which is null. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-2046) Merge join inconsistent results
[
https://issues.apache.org/jira/browse/DRILL-2046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacques Nadeau updated DRILL-2046:
--
Fix Version/s: (was: 1.0.0)
1.1.0
> Merge join inconsistent results
> ---
>
> Key: DRILL-2046
> URL: https://issues.apache.org/jira/browse/DRILL-2046
> Project: Apache Drill
> Issue Type: Bug
> Components: Execution - Relational Operators
>Reporter: Rahul Challapalli
>Assignee: Aman Sinha
>Priority: Critical
> Fix For: 1.1.0
>
> Attachments: widestrings_small.parquet
>
>
> git.commit.id.abbrev=a418af1
> The below queries should result in the same no of records. However the counts
> do not match when we use merge join.
> {code}
> alter session set `planner.enable_hashjoin` = false;
> select ws1.* from widestrings_small ws1 INNER JOIN widestrings_small ws2 on
> ws1.str_fixed_null_empty=ws2.str_var_null_empty where
> ws1.str_fixed_null_empty is not null and ws2.str_var_null_empty is not null
> and ws1.tinyint_var > 120;
> 6 records
> select count(*) from widestrings_small ws1 INNER JOIN widestrings_small ws2
> on ws1.str_fixed_null_empty=ws2.str_var_null_empty where
> ws1.str_fixed_null_empty is not null and ws2.str_var_null_empty is not null
> and ws1.tinyint_var > 120;
> 60 records
> select count(ws1.str_var) from widestrings_small ws1 INNER JOIN
> widestrings_small ws2 on ws1.str_fixed_null_empty=ws2.str_var_null_empty
> where ws1.str_fixed_null_empty is not null and ws2.str_var_null_empty is not
> null and ws1.tinyint_var > 120;
> 4 records
> {code}
> For hash join all the above queries result in 60 records. I attached the
> dataset used. Let me know if you have any questions.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (DRILL-1986) Natural join query returns wrong result
[
https://issues.apache.org/jira/browse/DRILL-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Victoria Markman closed DRILL-1986.
---
> Natural join query returns wrong result
> ---
>
> Key: DRILL-1986
> URL: https://issues.apache.org/jira/browse/DRILL-1986
> Project: Apache Drill
> Issue Type: Bug
> Components: Query Planning & Optimization
>Affects Versions: 0.8.0
>Reporter: Victoria Markman
>Assignee: Sean Hsuan-Yi Chu
> Labels: no_verified_test
>
> Natural join returns wrong result:
> {code}
> 0: jdbc:drill:schema=dfs> select * from `t1.json`;
> ++++
> | a1 | b1 | c1 |
> ++++
> | 1 | 1 | 2015-01-01 |
> | 2 | 2 | 2015-01-02 |
> ++++
> 2 rows selected (0.087 seconds)
> 0: jdbc:drill:schema=dfs> select * from `t2.json`;
> ++++
> | a1 | b1 | c1 |
> ++++
> | 1 | 1 | 2015-01-01 |
> ++++
> 1 row selected (0.112 seconds)
> 0: jdbc:drill:schema=dfs> select * from `t1.json` natural join `t2.json`;
> +++++++
> | a1 | b1 | c1 |a10 |b10 |c10
> |
> +++++++
> +++++++
> No rows selected (0.223 seconds)
> {code}
> Equivalent inner join query returns one row:
> {code}
> 0: jdbc:drill:schema=dfs> select * from `t1.json` t1, `t2.json` t2 where
> t1.a1=t2.a1 and t1.b1=t2.b1 and t1.c1=t2.c1;
> +++++++
> | a1 | b1 | c1 |a10 |b10 |c10
> |
> +++++++
> | 1 | 1 | 2015-01-01 | 1 | 1 | 2015-01-01
> |
> +++++++
> 1 row selected (0.732 seconds)
> {code}
> Natural join is listed as supported in our documentation.
> If we decide not to support it, we need to make sure to remove it from docs
> as well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DRILL-1986) Natural join query returns wrong result
[
https://issues.apache.org/jira/browse/DRILL-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Victoria Markman updated DRILL-1986:
Labels: no_verified_test (was: )
> Natural join query returns wrong result
> ---
>
> Key: DRILL-1986
> URL: https://issues.apache.org/jira/browse/DRILL-1986
> Project: Apache Drill
> Issue Type: Bug
> Components: Query Planning & Optimization
>Affects Versions: 0.8.0
>Reporter: Victoria Markman
>Assignee: Sean Hsuan-Yi Chu
> Labels: no_verified_test
>
> Natural join returns wrong result:
> {code}
> 0: jdbc:drill:schema=dfs> select * from `t1.json`;
> ++++
> | a1 | b1 | c1 |
> ++++
> | 1 | 1 | 2015-01-01 |
> | 2 | 2 | 2015-01-02 |
> ++++
> 2 rows selected (0.087 seconds)
> 0: jdbc:drill:schema=dfs> select * from `t2.json`;
> ++++
> | a1 | b1 | c1 |
> ++++
> | 1 | 1 | 2015-01-01 |
> ++++
> 1 row selected (0.112 seconds)
> 0: jdbc:drill:schema=dfs> select * from `t1.json` natural join `t2.json`;
> +++++++
> | a1 | b1 | c1 |a10 |b10 |c10
> |
> +++++++
> +++++++
> No rows selected (0.223 seconds)
> {code}
> Equivalent inner join query returns one row:
> {code}
> 0: jdbc:drill:schema=dfs> select * from `t1.json` t1, `t2.json` t2 where
> t1.a1=t2.a1 and t1.b1=t2.b1 and t1.c1=t2.c1;
> +++++++
> | a1 | b1 | c1 |a10 |b10 |c10
> |
> +++++++
> | 1 | 1 | 2015-01-01 | 1 | 1 | 2015-01-01
> |
> +++++++
> 1 row selected (0.732 seconds)
> {code}
> Natural join is listed as supported in our documentation.
> If we decide not to support it, we need to make sure to remove it from docs
> as well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DRILL-1986) Natural join query returns wrong result
[
https://issues.apache.org/jira/browse/DRILL-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14535710#comment-14535710
]
Victoria Markman commented on DRILL-1986:
-
Verified fixed in 1.0.0
#Thu May 07 19:07:43 EDT 2015
git.commit.id.abbrev=79a712a
0: jdbc:drill:schema=dfs> select * from t1 natural join t2;
Error: SYSTEM ERROR: NATURAL JOIN is not supported
See Apache Drill JIRA: DRILL-1986
[Error Id: 3f642783-5ac6-46b2-9497-94fba6ac2a72 on atsqa4-133.qa.lab:31010]
(state=,code=0)
> Natural join query returns wrong result
> ---
>
> Key: DRILL-1986
> URL: https://issues.apache.org/jira/browse/DRILL-1986
> Project: Apache Drill
> Issue Type: Bug
> Components: Query Planning & Optimization
>Affects Versions: 0.8.0
>Reporter: Victoria Markman
>Assignee: Sean Hsuan-Yi Chu
> Labels: no_verified_test
>
> Natural join returns wrong result:
> {code}
> 0: jdbc:drill:schema=dfs> select * from `t1.json`;
> ++++
> | a1 | b1 | c1 |
> ++++
> | 1 | 1 | 2015-01-01 |
> | 2 | 2 | 2015-01-02 |
> ++++
> 2 rows selected (0.087 seconds)
> 0: jdbc:drill:schema=dfs> select * from `t2.json`;
> ++++
> | a1 | b1 | c1 |
> ++++
> | 1 | 1 | 2015-01-01 |
> ++++
> 1 row selected (0.112 seconds)
> 0: jdbc:drill:schema=dfs> select * from `t1.json` natural join `t2.json`;
> +++++++
> | a1 | b1 | c1 |a10 |b10 |c10
> |
> +++++++
> +++++++
> No rows selected (0.223 seconds)
> {code}
> Equivalent inner join query returns one row:
> {code}
> 0: jdbc:drill:schema=dfs> select * from `t1.json` t1, `t2.json` t2 where
> t1.a1=t2.a1 and t1.b1=t2.b1 and t1.c1=t2.c1;
> +++++++
> | a1 | b1 | c1 |a10 |b10 |c10
> |
> +++++++
> | 1 | 1 | 2015-01-01 | 1 | 1 | 2015-01-01
> |
> +++++++
> 1 row selected (0.732 seconds)
> {code}
> Natural join is listed as supported in our documentation.
> If we decide not to support it, we need to make sure to remove it from docs
> as well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (DRILL-2441) Throw unsupported error message in case of inequality join
[
https://issues.apache.org/jira/browse/DRILL-2441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Victoria Markman closed DRILL-2441.
---
> Throw unsupported error message in case of inequality join
> --
>
> Key: DRILL-2441
> URL: https://issues.apache.org/jira/browse/DRILL-2441
> Project: Apache Drill
> Issue Type: Bug
> Components: Query Planning & Optimization
>Reporter: Victoria Markman
>Assignee: Aman Sinha
> Labels: no_verified_test
> Fix For: 0.8.0
>
> Attachments: DRILL-2441.1.patch
>
>
> Since we don't support inequality join, the whole class of queries will throw
> huge page long "Can't plan exception"
> This is a request to throw a nice error message that we throw in case of
> cartesian join in these cases as well.
> {code}
> select * from t1 left outer join t2 on (t1.a1 = t2.a2 and t1.b2 <> t2.b2);
> select * from t1 right outer join t2 on (t1.a1 = t2.a2 and t1.b2 <> t2.b2);
> {code}
> Example of an exception:
> {code}
> 0: jdbc:drill:schema=dfs> select * from t1 inner join t2 on(t1.b1 <> t2.b2);
> Query failed: UnsupportedRelOperatorException: This query cannot be planned
> possibly due to either a cartesian join or an inequality join
> 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-2793) Killing a non foreman node results in direct memory being held on
[
https://issues.apache.org/jira/browse/DRILL-2793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Westin updated DRILL-2793:
Assignee: Sudheesh Katkam (was: Chris Westin)
> Killing a non foreman node results in direct memory being held on
> -
>
> Key: DRILL-2793
> URL: https://issues.apache.org/jira/browse/DRILL-2793
> Project: Apache Drill
> Issue Type: Bug
> Components: Execution - Flow
>Affects Versions: 0.8.0
>Reporter: Ramana Inukonda Nagaraj
>Assignee: Sudheesh Katkam
> Fix For: 1.0.0
>
>
> Similar to DRILL-2792
> Happens for non foreman nodes as well.
> before:
> {code}
> 1/6 select * from sys.memory;
> +++--++++
> | hostname | user_port | heap_current | heap_max | direct_current |
> direct_max |
> +++--++++
> | atsqa6c62.qa.lab | 31010 | 72738752 | 4151836672 | 6048576
> | 34359738368 |
> | atsqa6c59.qa.lab | 31010 | 177100136| 4151836672 | 200
> | 34359738368 |
> | atsqa6c60.qa.lab | 31010 | 183895944| 4151836672 | 200
> | 34359738368 |
> | atsqa6c57.qa.lab | 31010 | 312198128| 4151836672 | 200
> | 34359738368 |
> | atsqa6c58.qa.lab | 31010 | 180850296| 4151836672 | 200
> | 34359738368 |
> | atsqa6c61.qa.lab | 31010 | 307163256| 4151836672 | 200
> | 34359738368 |
> | atsqa6c64.qa.lab | 31010 | 178883744| 4151836672 | 200
> | 34359738368 |
> | atsqa6c63.qa.lab | 31010 | 326312736| 4151836672 | 200
> | 34359738368 |
> +++--++++
> 8 rows selected (2.209 seconds)
> {code}
> After cancellation of non foreman node
> {code}
> 0: jdbc:drill:> select * from sys.memory;
> +++--++++
> | hostname | user_port | heap_current | heap_max | direct_current |
> direct_max |
> +++--++++
> | atsqa6c62.qa.lab | 31010 | 395684912| 4151836672 | 1745146306
> | 34359738368 |
> | atsqa6c57.qa.lab | 31010 | 416717016| 4151836672 | 1751348355
> | 34359738368 |
> | atsqa6c58.qa.lab | 31010 | 365235768| 4151836672 | 1713761930
> | 34359738368 |
> | atsqa6c59.qa.lab | 31010 | 409859856| 4151836672 | 1763119827
> | 34359738368 |
> | atsqa6c60.qa.lab | 31010 | 369571576| 4151836672 | 1759217229
> | 34359738368 |
> | atsqa6c63.qa.lab | 31010 | 469310224| 4151836672 | 1725239747
> | 34359738368 |
> | atsqa6c64.qa.lab | 31010 | 471814416| 4151836672 | 1735044144
> | 34359738368 |
> +++--++++
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DRILL-2441) Throw unsupported error message in case of inequality join
[
https://issues.apache.org/jira/browse/DRILL-2441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Victoria Markman updated DRILL-2441:
Labels: no_verified_test (was: )
> Throw unsupported error message in case of inequality join
> --
>
> Key: DRILL-2441
> URL: https://issues.apache.org/jira/browse/DRILL-2441
> Project: Apache Drill
> Issue Type: Bug
> Components: Query Planning & Optimization
>Reporter: Victoria Markman
>Assignee: Aman Sinha
> Labels: no_verified_test
> Fix For: 0.8.0
>
> Attachments: DRILL-2441.1.patch
>
>
> Since we don't support inequality join, the whole class of queries will throw
> huge page long "Can't plan exception"
> This is a request to throw a nice error message that we throw in case of
> cartesian join in these cases as well.
> {code}
> select * from t1 left outer join t2 on (t1.a1 = t2.a2 and t1.b2 <> t2.b2);
> select * from t1 right outer join t2 on (t1.a1 = t2.a2 and t1.b2 <> t2.b2);
> {code}
> Example of an exception:
> {code}
> 0: jdbc:drill:schema=dfs> select * from t1 inner join t2 on(t1.b1 <> t2.b2);
> Query failed: UnsupportedRelOperatorException: This query cannot be planned
> possibly due to either a cartesian join or an inequality join
> 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-2441) Throw unsupported error message in case of inequality join
[
https://issues.apache.org/jira/browse/DRILL-2441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14535690#comment-14535690
]
Victoria Markman commented on DRILL-2441:
-
Verified fixed in: 1.0.0
#Thu May 07 19:07:43 EDT 2015
git.commit.id.abbrev=79a712a
0: jdbc:drill:schema=dfs> select * from t1 left outer join t2 on (t1.a1 =
t2.a2 and t1.b2 <> t2.b2);
Error: SYSTEM ERROR: This query cannot be planned possibly due to either a
cartesian join or an inequality join
[Error Id: ee0aa885-1aca-419b-b5f0-65fd992451dc on atsqa4-133.qa.lab:31010]
(state=,code=0)
> Throw unsupported error message in case of inequality join
> --
>
> Key: DRILL-2441
> URL: https://issues.apache.org/jira/browse/DRILL-2441
> Project: Apache Drill
> Issue Type: Bug
> Components: Query Planning & Optimization
>Reporter: Victoria Markman
>Assignee: Aman Sinha
> Labels: no_verified_test
> Fix For: 0.8.0
>
> Attachments: DRILL-2441.1.patch
>
>
> Since we don't support inequality join, the whole class of queries will throw
> huge page long "Can't plan exception"
> This is a request to throw a nice error message that we throw in case of
> cartesian join in these cases as well.
> {code}
> select * from t1 left outer join t2 on (t1.a1 = t2.a2 and t1.b2 <> t2.b2);
> select * from t1 right outer join t2 on (t1.a1 = t2.a2 and t1.b2 <> t2.b2);
> {code}
> Example of an exception:
> {code}
> 0: jdbc:drill:schema=dfs> select * from t1 inner join t2 on(t1.b1 <> t2.b2);
> Query failed: UnsupportedRelOperatorException: This query cannot be planned
> possibly due to either a cartesian join or an inequality join
> 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-2792) Killing the drillbit which is the foreman results in direct memory being held on
[ https://issues.apache.org/jira/browse/DRILL-2792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Westin updated DRILL-2792: Assignee: Sudheesh Katkam (was: Chris Westin) > Killing the drillbit which is the foreman results in direct memory being held > on > > > Key: DRILL-2792 > URL: https://issues.apache.org/jira/browse/DRILL-2792 > Project: Apache Drill > Issue Type: Bug > Components: Execution - Flow >Affects Versions: 0.8.0 >Reporter: Ramana Inukonda Nagaraj >Assignee: Sudheesh Katkam > Fix For: 1.0.0 > > > Killed one of the drillbits which is the foreman for the query- > Profiles page reports that query has cancelled. > Due to bug Drill-2778 sqlline hangs. However after killing sqlline the > current direct memory used does not go down to pre query levels. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-2961) Statement.setQueryTimeout() should throw a SQLException
[ https://issues.apache.org/jira/browse/DRILL-2961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Nadeau updated DRILL-2961: -- Assignee: Parth Chandra (was: Daniel Barclay (Drill)) > 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: Parth Chandra > Fix For: 1.0.0 > > Attachments: DRILL-2961.1Prep.2.patch.txt, > DRILL-2961.1Prep.3.patch.txt, DRILL-2961.1Prep.4.patch.txt, > DRILL-2961.2Core.2.patch.txt, DRILL-2961.2Core.3.patch.txt, > DRILL-2961.2Core.4.patch.txt > > > 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] [Closed] (DRILL-3000) I got JIRA report #3000. Now ... to use it for good or evil?
[ https://issues.apache.org/jira/browse/DRILL-3000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hanifi Gunes closed DRILL-3000. --- Resolution: Fixed This was a though fix. > I got JIRA report #3000. Now ... to use it for good or evil? > - > > Key: DRILL-3000 > URL: https://issues.apache.org/jira/browse/DRILL-3000 > Project: Apache Drill > Issue Type: Bug >Reporter: Daniel Barclay (Drill) >Assignee: Daniel Barclay (Drill) > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-3000) I got JIRA report #3000. Now ... to use it for good or evil?
[ https://issues.apache.org/jira/browse/DRILL-3000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Barclay (Drill) updated DRILL-3000: -- Summary: I got JIRA report #3000. Now ... to use it for good or evil? (was: 3k!) > I got JIRA report #3000. Now ... to use it for good or evil? > - > > Key: DRILL-3000 > URL: https://issues.apache.org/jira/browse/DRILL-3000 > Project: Apache Drill > Issue Type: Bug >Reporter: Daniel Barclay (Drill) >Assignee: Daniel Barclay (Drill) > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DRILL-3000) 3k!
[ https://issues.apache.org/jira/browse/DRILL-3000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14535666#comment-14535666 ] Aditya Kishore commented on DRILL-3000: --- You beat Ramana and me to it :) > 3k! > --- > > Key: DRILL-3000 > URL: https://issues.apache.org/jira/browse/DRILL-3000 > Project: Apache Drill > Issue Type: Bug >Reporter: Daniel Barclay (Drill) >Assignee: Daniel Barclay (Drill) > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (DRILL-3000) 3k!
Daniel Barclay (Drill) created DRILL-3000: - Summary: 3k! Key: DRILL-3000 URL: https://issues.apache.org/jira/browse/DRILL-3000 Project: Apache Drill Issue Type: Bug Reporter: Daniel Barclay (Drill) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-2999) Parse-error exception logged to stdout/stderr (visible in SQLLine output)
[
https://issues.apache.org/jira/browse/DRILL-2999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Barclay (Drill) updated DRILL-2999:
--
Description:
For some Calcite/parsing exceptions that seem to be internal (seem to be caught
and processed (translated) at a higher level), Calcite or parsing logging is
writing "SEVERE"-level logging messages to stdout or stderr.
When SQLLine runs Drill in embedded mode, those logging lines show up
intermixed in the SQLLine output"
{noformat}
0: jdbc:drill:zk=local> bad syntax;
May 08, 2015 2:42:23 PM org.apache.calcite.runtime.CalciteException
SEVERE: org.apache.calcite.runtime.CalciteException: Non-query expression
encountered in illegal context
May 08, 2015 2:42:23 PM org.apache.calcite.runtime.CalciteException
SEVERE: org.apache.calcite.runtime.CalciteContextException: From line 1, column
1 to line 1, column 3: Non-query expression encountered in illegal context
Error: SYSTEM ERROR: Failure parsing SQL. Non-query expression encountered in
illegal context
[Error Id: 87c20db6-58b1-4042-9060-42ee29945377 on dev-linux2:31016]
(state=,code=0)
0: jdbc:drill:zk=local>
{noformat}
(The "Error: SYSTEM ..." lines are the normal error from SQLLine including
exception message text from Drill. The four lines starting with "May" or
"SEVERE" are the extraneous logging output.)
was:
For some Calcite/parsing exceptions that seem to be internal (seem to be caught
and processed at a higher level), Calcite or parsing logging is writing
"SEVERE"-level logging messages to stdout or stderr.
When SQLLine runs Drill in embedded mode, those logging lines show up
intermixed in the SQLLine output"
{noformat}
0: jdbc:drill:zk=local> bad syntax;
May 08, 2015 2:42:23 PM org.apache.calcite.runtime.CalciteException
SEVERE: org.apache.calcite.runtime.CalciteException: Non-query expression
encountered in illegal context
May 08, 2015 2:42:23 PM org.apache.calcite.runtime.CalciteException
SEVERE: org.apache.calcite.runtime.CalciteContextException: From line 1, column
1 to line 1, column 3: Non-query expression encountered in illegal context
Error: SYSTEM ERROR: Failure parsing SQL. Non-query expression encountered in
illegal context
[Error Id: 87c20db6-58b1-4042-9060-42ee29945377 on dev-linux2:31016]
(state=,code=0)
0: jdbc:drill:zk=local>
{noformat}
(The "Error: SYSTEM ..." lines are the normal error from SQLLine including
exception message text from Drill. The four lines starting with "May" or
"SEVERE" are the extraneous logging output.)
> Parse-error exception logged to stdout/stderr (visible in SQLLine output)
> -
>
> Key: DRILL-2999
> URL: https://issues.apache.org/jira/browse/DRILL-2999
> Project: Apache Drill
> Issue Type: Bug
> Components: SQL Parser
>Reporter: Daniel Barclay (Drill)
>
> For some Calcite/parsing exceptions that seem to be internal (seem to be
> caught and processed (translated) at a higher level), Calcite or parsing
> logging is writing "SEVERE"-level logging messages to stdout or stderr.
> When SQLLine runs Drill in embedded mode, those logging lines show up
> intermixed in the SQLLine output"
> {noformat}
> 0: jdbc:drill:zk=local> bad syntax;
> May 08, 2015 2:42:23 PM org.apache.calcite.runtime.CalciteException
> SEVERE: org.apache.calcite.runtime.CalciteException: Non-query expression
> encountered in illegal context
> May 08, 2015 2:42:23 PM org.apache.calcite.runtime.CalciteException
> SEVERE: org.apache.calcite.runtime.CalciteContextException: From line 1,
> column 1 to line 1, column 3: Non-query expression encountered in illegal
> context
> Error: SYSTEM ERROR: Failure parsing SQL. Non-query expression encountered in
> illegal context
> [Error Id: 87c20db6-58b1-4042-9060-42ee29945377 on dev-linux2:31016]
> (state=,code=0)
> 0: jdbc:drill:zk=local>
> {noformat}
> (The "Error: SYSTEM ..." lines are the normal error from SQLLine including
> exception message text from Drill. The four lines starting with "May" or
> "SEVERE" are the extraneous logging output.)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (DRILL-3000) 3k!
[ https://issues.apache.org/jira/browse/DRILL-3000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Barclay (Drill) reassigned DRILL-3000: - Assignee: Daniel Barclay (Drill) > 3k! > --- > > Key: DRILL-3000 > URL: https://issues.apache.org/jira/browse/DRILL-3000 > Project: Apache Drill > Issue Type: Bug >Reporter: Daniel Barclay (Drill) >Assignee: Daniel Barclay (Drill) > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (DRILL-2999) Parse-error exception logged to stdout/stderr (visible in SQLLine output)
Daniel Barclay (Drill) created DRILL-2999:
-
Summary: Parse-error exception logged to stdout/stderr (visible in
SQLLine output)
Key: DRILL-2999
URL: https://issues.apache.org/jira/browse/DRILL-2999
Project: Apache Drill
Issue Type: Bug
Reporter: Daniel Barclay (Drill)
For some Calcite/parsing exceptions that seem to be internal (seem to be caught
and processed at a higher level), Calcite or parsing logging is writing
"SEVERE"-level logging messages to stdout or stderr.
When SQLLine runs Drill in embedded mode, those logging lines show up
intermixed in the SQLLine output"
{noformat}
0: jdbc:drill:zk=local> bad syntax;
May 08, 2015 2:42:23 PM org.apache.calcite.runtime.CalciteException
SEVERE: org.apache.calcite.runtime.CalciteException: Non-query expression
encountered in illegal context
May 08, 2015 2:42:23 PM org.apache.calcite.runtime.CalciteException
SEVERE: org.apache.calcite.runtime.CalciteContextException: From line 1, column
1 to line 1, column 3: Non-query expression encountered in illegal context
Error: SYSTEM ERROR: Failure parsing SQL. Non-query expression encountered in
illegal context
[Error Id: 87c20db6-58b1-4042-9060-42ee29945377 on dev-linux2:31016]
(state=,code=0)
0: jdbc:drill:zk=local>
{noformat}
(The "Error: SYSTEM ..." lines are the normal error from SQLLine including
exception message text from Drill. The four lines starting with "May" or
"SEVERE" are the extraneous logging output.)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DRILL-2999) Parse-error exception logged to stdout/stderr (visible in SQLLine output)
[
https://issues.apache.org/jira/browse/DRILL-2999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Barclay (Drill) updated DRILL-2999:
--
Component/s: SQL Parser
> Parse-error exception logged to stdout/stderr (visible in SQLLine output)
> -
>
> Key: DRILL-2999
> URL: https://issues.apache.org/jira/browse/DRILL-2999
> Project: Apache Drill
> Issue Type: Bug
> Components: SQL Parser
>Reporter: Daniel Barclay (Drill)
>
> For some Calcite/parsing exceptions that seem to be internal (seem to be
> caught and processed at a higher level), Calcite or parsing logging is
> writing "SEVERE"-level logging messages to stdout or stderr.
> When SQLLine runs Drill in embedded mode, those logging lines show up
> intermixed in the SQLLine output"
> {noformat}
> 0: jdbc:drill:zk=local> bad syntax;
> May 08, 2015 2:42:23 PM org.apache.calcite.runtime.CalciteException
> SEVERE: org.apache.calcite.runtime.CalciteException: Non-query expression
> encountered in illegal context
> May 08, 2015 2:42:23 PM org.apache.calcite.runtime.CalciteException
> SEVERE: org.apache.calcite.runtime.CalciteContextException: From line 1,
> column 1 to line 1, column 3: Non-query expression encountered in illegal
> context
> Error: SYSTEM ERROR: Failure parsing SQL. Non-query expression encountered in
> illegal context
> [Error Id: 87c20db6-58b1-4042-9060-42ee29945377 on dev-linux2:31016]
> (state=,code=0)
> 0: jdbc:drill:zk=local>
> {noformat}
> (The "Error: SYSTEM ..." lines are the normal error from SQLLine including
> exception message text from Drill. The four lines starting with "May" or
> "SEVERE" are the extraneous logging output.)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (DRILL-2089) Split JDBC implementation out of org.apache.drill.jdbc, so that pkg. is place for doc.
[
https://issues.apache.org/jira/browse/DRILL-2089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14488333#comment-14488333
]
Daniel Barclay (Drill) edited comment on DRILL-2089 at 5/8/15 9:27 PM:
---
DRILL-2089 move was started in DRILL-2613 work: old class DrillResultSet split
into interface DrillResultSet and class DrillResultSetImpl.
was (Author: dsbos):
DRILL-2089 move started in DRILL-2613 work: old class DrillResultSet split
into interface DrillResultSet and class DrillResultSetImpl.
> Split JDBC implementation out of org.apache.drill.jdbc, so that pkg. is place
> for doc.
> --
>
> Key: DRILL-2089
> URL: https://issues.apache.org/jira/browse/DRILL-2089
> Project: Apache Drill
> Issue Type: Improvement
> Components: Client - JDBC
>Reporter: Daniel Barclay (Drill)
>Assignee: Daniel Barclay (Drill)
> Fix For: Future
>
>
> The JDBC implementation classes and interfaces that are not part of Drill's
> published JDBC interface should be moved out of package org.apache.drill.jdbc.
> This will support using Javadoc to produce end-user documentation of
> Drill-specific JDBC API behavior (e.g., what's implemented or not, plus any
> extensions), and keep clear what is part of Drill's published JDBC interface
> vs. what is not (i.e., items that are technically accessible (public or
> protected) but _not_ meant to be used by Drill users).
> Parts:
> 1. Move most classes and packages in {{org.apache.drill.jdbc}} (e.g.,
> {{DrillHandler}}, {{DrillConnectionImpl}}) to an implementation package
> (e.g., {{org.apache.drill.jdbc.impl}}).
> 2. Split the current {{org.apache.drill.jdbc.Driver}} into a
> published-interface portion still at {{org.apache.drill.jdbc.Driver}} plus an
> implementation portion at {{org.apache.drill.jdbc.impl.DriverImpl}}.
> ({{org.apache.drill.jdbc.Driver}} would expose only the published interface
> (e.g., its constructor and methods from {{java.sql.Driver}}).
> {{org.apache.drill.jdbc.impl.DriverImpl}} would contain methods that are not
> part of Drill's published JDBC interface (including methods that need to be
> public or protected because of using Avatica but which shouldn't be used by
> Drill users).)
> 3. As needed (for Drill extensions and for documentation), create
> Drill-specific interfaces extending standard JDBC interfaces.
> For example, to create a place for documenting Drill-specific behavior of
> methods defined in {{java.sql.Connection}}, create an interface, e.g.,
> {{org.apache.drill.jdbc.DrillConnection}}, that extends interface
> {{java.sql.Connection}}, adjust the internal implementation class in
> {{org.apache.drill.jdbc.impl}} to implement that Drill-specified interface
> rather than directly implementing {{java.sql.Connection}}, and then add a
> method declaration with the Drill-specific documentation to the
> Drill-specific subinterface.
> 4. In Drill-specific interfaces created per part 3, _consider_ using
> co-variant return types to narrow return types to the Drill-specific
> interfaces.
> For example: {{java.sql.Connection}}'s {{createStatement()}} method returns
> type {{java.sql.Statement}}. Drill's implementation of that method will
> always return a Drill-specific implementation of {{java.sql.Statement}},
> which will also be an implementation of the Drill-specific interface that
> extends {{java.sql.Statement}}. Therefore, the Drill-specific {{Connection}}
> interface can re-declare {{createStatement()}} as returning the
> Drill-specific {{Statement}} interface type (because the Drill-specific
> {{Statement}} type is a subtype of {{java.sql.Statement}}).
> That would likely make it easier for client code to access any Drill
> extension methods: Although the client might have to cast or do something
> else special to get to the first Drill-specific interface or class, it could
> traverse to other objects (e.g., from connection to statement, from statement
> to result set, etc.) still using Drill-specific types, not needing casts or
> whatever as each step.
> Note: Steps 1 and 2 have already been prototyped.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (DRILL-2089) Split JDBC implementation out of org.apache.drill.jdbc, so that pkg. is place for doc.
[
https://issues.apache.org/jira/browse/DRILL-2089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14535569#comment-14535569
]
Daniel Barclay (Drill) edited comment on DRILL-2089 at 5/8/15 9:27 PM:
---
DRILL-2089 move was implemented a bit more in DRILL-2961 work: old class
...jdbc.DrillStatement split into interface ...jdbc.DrillStatement and class
...jdbc.impl.DrillStatementImpl.
was (Author: dsbos):
DRILL-2089 move "incremented" in started in DRILL-2961 work: old class
...jdbc.DrillStatement split into interface ...jdbc.DrillStatement and class
...jdbc.impl.DrillStatementImpl.
> Split JDBC implementation out of org.apache.drill.jdbc, so that pkg. is place
> for doc.
> --
>
> Key: DRILL-2089
> URL: https://issues.apache.org/jira/browse/DRILL-2089
> Project: Apache Drill
> Issue Type: Improvement
> Components: Client - JDBC
>Reporter: Daniel Barclay (Drill)
>Assignee: Daniel Barclay (Drill)
> Fix For: Future
>
>
> The JDBC implementation classes and interfaces that are not part of Drill's
> published JDBC interface should be moved out of package org.apache.drill.jdbc.
> This will support using Javadoc to produce end-user documentation of
> Drill-specific JDBC API behavior (e.g., what's implemented or not, plus any
> extensions), and keep clear what is part of Drill's published JDBC interface
> vs. what is not (i.e., items that are technically accessible (public or
> protected) but _not_ meant to be used by Drill users).
> Parts:
> 1. Move most classes and packages in {{org.apache.drill.jdbc}} (e.g.,
> {{DrillHandler}}, {{DrillConnectionImpl}}) to an implementation package
> (e.g., {{org.apache.drill.jdbc.impl}}).
> 2. Split the current {{org.apache.drill.jdbc.Driver}} into a
> published-interface portion still at {{org.apache.drill.jdbc.Driver}} plus an
> implementation portion at {{org.apache.drill.jdbc.impl.DriverImpl}}.
> ({{org.apache.drill.jdbc.Driver}} would expose only the published interface
> (e.g., its constructor and methods from {{java.sql.Driver}}).
> {{org.apache.drill.jdbc.impl.DriverImpl}} would contain methods that are not
> part of Drill's published JDBC interface (including methods that need to be
> public or protected because of using Avatica but which shouldn't be used by
> Drill users).)
> 3. As needed (for Drill extensions and for documentation), create
> Drill-specific interfaces extending standard JDBC interfaces.
> For example, to create a place for documenting Drill-specific behavior of
> methods defined in {{java.sql.Connection}}, create an interface, e.g.,
> {{org.apache.drill.jdbc.DrillConnection}}, that extends interface
> {{java.sql.Connection}}, adjust the internal implementation class in
> {{org.apache.drill.jdbc.impl}} to implement that Drill-specified interface
> rather than directly implementing {{java.sql.Connection}}, and then add a
> method declaration with the Drill-specific documentation to the
> Drill-specific subinterface.
> 4. In Drill-specific interfaces created per part 3, _consider_ using
> co-variant return types to narrow return types to the Drill-specific
> interfaces.
> For example: {{java.sql.Connection}}'s {{createStatement()}} method returns
> type {{java.sql.Statement}}. Drill's implementation of that method will
> always return a Drill-specific implementation of {{java.sql.Statement}},
> which will also be an implementation of the Drill-specific interface that
> extends {{java.sql.Statement}}. Therefore, the Drill-specific {{Connection}}
> interface can re-declare {{createStatement()}} as returning the
> Drill-specific {{Statement}} interface type (because the Drill-specific
> {{Statement}} type is a subtype of {{java.sql.Statement}}).
> That would likely make it easier for client code to access any Drill
> extension methods: Although the client might have to cast or do something
> else special to get to the first Drill-specific interface or class, it could
> traverse to other objects (e.g., from connection to statement, from statement
> to result set, etc.) still using Drill-specific types, not needing casts or
> whatever as each step.
> Note: Steps 1 and 2 have already been prototyped.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DRILL-2089) Split JDBC implementation out of org.apache.drill.jdbc, so that pkg. is place for doc.
[
https://issues.apache.org/jira/browse/DRILL-2089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14535569#comment-14535569
]
Daniel Barclay (Drill) commented on DRILL-2089:
---
DRILL-2089 move "incremented" in started in DRILL-2961 work: old class
...jdbc.DrillStatement split into interface ...jdbc.DrillStatement and class
...jdbc.impl.DrillStatementImpl.
> Split JDBC implementation out of org.apache.drill.jdbc, so that pkg. is place
> for doc.
> --
>
> Key: DRILL-2089
> URL: https://issues.apache.org/jira/browse/DRILL-2089
> Project: Apache Drill
> Issue Type: Improvement
> Components: Client - JDBC
>Reporter: Daniel Barclay (Drill)
>Assignee: Daniel Barclay (Drill)
> Fix For: Future
>
>
> The JDBC implementation classes and interfaces that are not part of Drill's
> published JDBC interface should be moved out of package org.apache.drill.jdbc.
> This will support using Javadoc to produce end-user documentation of
> Drill-specific JDBC API behavior (e.g., what's implemented or not, plus any
> extensions), and keep clear what is part of Drill's published JDBC interface
> vs. what is not (i.e., items that are technically accessible (public or
> protected) but _not_ meant to be used by Drill users).
> Parts:
> 1. Move most classes and packages in {{org.apache.drill.jdbc}} (e.g.,
> {{DrillHandler}}, {{DrillConnectionImpl}}) to an implementation package
> (e.g., {{org.apache.drill.jdbc.impl}}).
> 2. Split the current {{org.apache.drill.jdbc.Driver}} into a
> published-interface portion still at {{org.apache.drill.jdbc.Driver}} plus an
> implementation portion at {{org.apache.drill.jdbc.impl.DriverImpl}}.
> ({{org.apache.drill.jdbc.Driver}} would expose only the published interface
> (e.g., its constructor and methods from {{java.sql.Driver}}).
> {{org.apache.drill.jdbc.impl.DriverImpl}} would contain methods that are not
> part of Drill's published JDBC interface (including methods that need to be
> public or protected because of using Avatica but which shouldn't be used by
> Drill users).)
> 3. As needed (for Drill extensions and for documentation), create
> Drill-specific interfaces extending standard JDBC interfaces.
> For example, to create a place for documenting Drill-specific behavior of
> methods defined in {{java.sql.Connection}}, create an interface, e.g.,
> {{org.apache.drill.jdbc.DrillConnection}}, that extends interface
> {{java.sql.Connection}}, adjust the internal implementation class in
> {{org.apache.drill.jdbc.impl}} to implement that Drill-specified interface
> rather than directly implementing {{java.sql.Connection}}, and then add a
> method declaration with the Drill-specific documentation to the
> Drill-specific subinterface.
> 4. In Drill-specific interfaces created per part 3, _consider_ using
> co-variant return types to narrow return types to the Drill-specific
> interfaces.
> For example: {{java.sql.Connection}}'s {{createStatement()}} method returns
> type {{java.sql.Statement}}. Drill's implementation of that method will
> always return a Drill-specific implementation of {{java.sql.Statement}},
> which will also be an implementation of the Drill-specific interface that
> extends {{java.sql.Statement}}. Therefore, the Drill-specific {{Connection}}
> interface can re-declare {{createStatement()}} as returning the
> Drill-specific {{Statement}} interface type (because the Drill-specific
> {{Statement}} type is a subtype of {{java.sql.Statement}}).
> That would likely make it easier for client code to access any Drill
> extension methods: Although the client might have to cast or do something
> else special to get to the first Drill-specific interface or class, it could
> traverse to other objects (e.g., from connection to statement, from statement
> to result set, etc.) still using Drill-specific types, not needing casts or
> whatever as each step.
> Note: Steps 1 and 2 have already been prototyped.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (DRILL-1818) Parquet files generated by Drill ignore field names when nested elements are queried
[
https://issues.apache.org/jira/browse/DRILL-1818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rahul Challapalli closed DRILL-1818.
Verified and added the below testcase
Functional/Passing/parquet_storage/parquet_generic/parquet_DRILL-1818.q
> Parquet files generated by Drill ignore field names when nested elements are
> queried
>
>
> Key: DRILL-1818
> URL: https://issues.apache.org/jira/browse/DRILL-1818
> Project: Apache Drill
> Issue Type: Bug
> Components: Storage - Writer
>Reporter: Neeraja
>Assignee: Steven Phillips
>Priority: Blocker
> Fix For: 0.7.0
>
> Attachments: 0_0_0.parquet, DRILL-1818.patch
>
>
> I observed this with this parquet file and a more comprehensive testing might
> be needed here. The issue is that Drill seem to simply ignore field names at
> the leaf level and accessing data in a positional fashion.
> Below is the repro.
> 1. Generate a parquet file using Drill. Input is the JSON doc below
> create table dfs.tmp.sampleparquet as (select trans_id, cast(`date` as date)
> transdate,cast(`time` as time) transtime, cast(amount as double)
> amount,`user_info`,`marketing_info`, `trans_info` from
> dfs.`/Users/nrentachintala/Downloads/sample.json` )
> 2. Now do queries.
> Note in query below, there is no field name called 'keywords' in trans_info,
> but data is just positionally returned (the data returned from prod_id
> column).
> 0: jdbc:drill:zk=local> select t.`trans_info`.keywords from
> dfs.tmp.sampleparquet t where t.`trans_info`.keywords is not null;
> ++
> | EXPR$0 |
> ++
> | [16] |
> | [] |
> | [293,90] |
> | [173,18,121,84,115,226,464,525,35,11,94,45] |
> | [311,29,5,41] |
> 0: jdbc:drill:zk=local> select t.`marketing_info`.keywords from
> dfs.tmp.sampleparquet t;
> Note in the query below, it is trying to return the first element in
> marketing_Info which is camp_id which is of int type for keywords columns.
> But keywords schema is string, so it throws error with type mismatch.
> Query failed: Query failed: Failure while running fragment., You tried to
> write a VarChar type when you are using a ValueWriter of type
> NullableBigIntWriterImpl. [ c3761403-b8c5-43c1-8e90-2c4918d1f85c on
> 10.0.0.20:31010 ]
> [ c3761403-b8c5-43c1-8e90-2c4918d1f85c on 10.0.0.20:31010 ]
> Error: exception while executing query: Failure while executing query.
> (state=,code=0)
> 0: jdbc:drill:zk=local> select
> t.`marketing_info`.`camp_id`,t.`marketing_info`.keywords from
> dfs.tmp.sampleparquet t;
> +++
> | EXPR$0 | EXPR$1 |
> +++
> | 4 |
> ["go","to","thing","watch","made","laughing","might","pay","in","your","hold"]
> |
> | 6 | ["pronounce","tree","instead","games","sigh"] |
> | 17 | [] |
> | 17 | ["it's"] |
> | 8 | ["fallout"] |
> +++
> Sample.json is below
> {"trans_id":0,"date":"2013-07-26","time":"04:56:59","amount":80.5,"user_info":{"cust_id":28,"device":"IOS5","state":"mt"},"marketing_info":{"camp_id":4,"keywords":["go","to","thing","watch","made","laughing","might","pay","in","your","hold"]},"trans_info":{"prod_id":[16],"purch_flag":"false"}}
> {"trans_id":1,"date":"2013-05-16","time":"07:31:54","amount":100.40,
> "user_info":{"cust_id":86623,"device":"AOS4.2","state":"mi"},"marketing_info":{"camp_id":6,"keywords":["pronounce","tree","instead","games","sigh"]},"trans_info":{"prod_id":[],"purch_flag":"false"}}
> {"trans_id":2,"date":"2013-06-09","time":"15:31:45","amount":20.25,
> "user_info":{"cust_id":11,"device":"IOS5","state":"la"},"marketing_info":{"camp_id":17,"keywords":[]},"trans_info":{"prod_id":[293,90],"purch_flag":"true"}}
> {"trans_id":3,"date":"2013-07-19","time":"11:24:22","amount":500.75,
> "user_info":{"cust_id":666,"device":"IOS5","state":"nj"},"marketing_info":{"camp_id":17,"keywords":["it's"]},"trans_info":{"prod_id":[173,18,121,84,115,226,464,525,35,11,94,45],"purch_flag":"false"}}
> {"trans_id":4,"date":"2013-07-21","time":"08:01:13","amount":34.20,"user_info":{"cust_id":999,"device":"IOS7","state":"ct"},"marketing_info":{"camp_id":8,"keywords":["fallout"]},"trans_info":{"prod_id":[311,29,5,41],"purch_flag":"false"}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (DRILL-2089) Split JDBC implementation out of org.apache.drill.jdbc, so that pkg. is place for doc.
[
https://issues.apache.org/jira/browse/DRILL-2089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14488333#comment-14488333
]
Daniel Barclay (Drill) edited comment on DRILL-2089 at 5/8/15 9:21 PM:
---
DRILL-2089 move started in DRILL-2613 work: old class DrillResultSet split
into interface DrillResultSet and class DrillResultSetImpl.
was (Author: dsbos):
DRILL-2098 move started in DRILL-2613 work: old class DrillResultSet split
into interface DrillResultSet and class DrillResultSetImpl.
> Split JDBC implementation out of org.apache.drill.jdbc, so that pkg. is place
> for doc.
> --
>
> Key: DRILL-2089
> URL: https://issues.apache.org/jira/browse/DRILL-2089
> Project: Apache Drill
> Issue Type: Improvement
> Components: Client - JDBC
>Reporter: Daniel Barclay (Drill)
>Assignee: Daniel Barclay (Drill)
> Fix For: Future
>
>
> The JDBC implementation classes and interfaces that are not part of Drill's
> published JDBC interface should be moved out of package org.apache.drill.jdbc.
> This will support using Javadoc to produce end-user documentation of
> Drill-specific JDBC API behavior (e.g., what's implemented or not, plus any
> extensions), and keep clear what is part of Drill's published JDBC interface
> vs. what is not (i.e., items that are technically accessible (public or
> protected) but _not_ meant to be used by Drill users).
> Parts:
> 1. Move most classes and packages in {{org.apache.drill.jdbc}} (e.g.,
> {{DrillHandler}}, {{DrillConnectionImpl}}) to an implementation package
> (e.g., {{org.apache.drill.jdbc.impl}}).
> 2. Split the current {{org.apache.drill.jdbc.Driver}} into a
> published-interface portion still at {{org.apache.drill.jdbc.Driver}} plus an
> implementation portion at {{org.apache.drill.jdbc.impl.DriverImpl}}.
> ({{org.apache.drill.jdbc.Driver}} would expose only the published interface
> (e.g., its constructor and methods from {{java.sql.Driver}}).
> {{org.apache.drill.jdbc.impl.DriverImpl}} would contain methods that are not
> part of Drill's published JDBC interface (including methods that need to be
> public or protected because of using Avatica but which shouldn't be used by
> Drill users).)
> 3. As needed (for Drill extensions and for documentation), create
> Drill-specific interfaces extending standard JDBC interfaces.
> For example, to create a place for documenting Drill-specific behavior of
> methods defined in {{java.sql.Connection}}, create an interface, e.g.,
> {{org.apache.drill.jdbc.DrillConnection}}, that extends interface
> {{java.sql.Connection}}, adjust the internal implementation class in
> {{org.apache.drill.jdbc.impl}} to implement that Drill-specified interface
> rather than directly implementing {{java.sql.Connection}}, and then add a
> method declaration with the Drill-specific documentation to the
> Drill-specific subinterface.
> 4. In Drill-specific interfaces created per part 3, _consider_ using
> co-variant return types to narrow return types to the Drill-specific
> interfaces.
> For example: {{java.sql.Connection}}'s {{createStatement()}} method returns
> type {{java.sql.Statement}}. Drill's implementation of that method will
> always return a Drill-specific implementation of {{java.sql.Statement}},
> which will also be an implementation of the Drill-specific interface that
> extends {{java.sql.Statement}}. Therefore, the Drill-specific {{Connection}}
> interface can re-declare {{createStatement()}} as returning the
> Drill-specific {{Statement}} interface type (because the Drill-specific
> {{Statement}} type is a subtype of {{java.sql.Statement}}).
> That would likely make it easier for client code to access any Drill
> extension methods: Although the client might have to cast or do something
> else special to get to the first Drill-specific interface or class, it could
> traverse to other objects (e.g., from connection to statement, from statement
> to result set, etc.) still using Drill-specific types, not needing casts or
> whatever as each step.
> Note: Steps 1 and 2 have already been prototyped.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DRILL-2973) Error messages not showing up in sqlline
[
https://issues.apache.org/jira/browse/DRILL-2973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14535549#comment-14535549
]
Daniel Barclay (Drill) commented on DRILL-2973:
---
Fixed by DRILL-2932 fix.
> Error messages not showing up in sqlline
>
>
> Key: DRILL-2973
> URL: https://issues.apache.org/jira/browse/DRILL-2973
> Project: Apache Drill
> Issue Type: Bug
> Components: Execution - Flow
>Reporter: Rahul Challapalli
>Assignee: Daniel Barclay (Drill)
>Priority: Blocker
> Labels: error_message_must_fix
> Fix For: 1.0.0
>
> Attachments: error.log
>
>
> git.commit.id.abbrev=3b19076
> This could be a regression. I am not seeing any error messages. Below are
> some of the cases
> {code}
> 0: jdbc:drill:schema=dfs_eea> select * from sdkjgfhsjkdgf;
> Error: exception while executing query: Failure while executing query.
> (state=,code=0)
> {code}
> The logs have the right messages. For some reason they are not being
> propagated to sqlline. I attached the error log.
> {code}
> 0: jdbc:drill:schema=dfs_eea> this is crap;
> 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] [Resolved] (DRILL-2972) Error message not clear when we try to select a field within a map without using an alias
[
https://issues.apache.org/jira/browse/DRILL-2972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Barclay (Drill) resolved DRILL-2972.
---
Resolution: Fixed
Fixed by DRILL-2932 fix.
> Error message not clear when we try to select a field within a map without
> using an alias
> -
>
> Key: DRILL-2972
> URL: https://issues.apache.org/jira/browse/DRILL-2972
> Project: Apache Drill
> Issue Type: Bug
> Components: Query Planning & Optimization
>Reporter: Rahul Challapalli
>Assignee: Jinfeng Ni
> Fix For: 1.2.0
>
>
> git.commit.id.abbrev=3b19076
> When I try to access a field within a map (without using an alias), below is
> the error I get.
> {code}
> 0: jdbc:drill:schema=dfs_eea> select map.rm from `data.json`;
> Error: exception while executing query: Failure while executing query.
> (state=,code=0)
> {code}
> There is no message from drill and the chances of users hitting this scenario
> is very high. So I am marking this as critical.
--
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
]
Jason Altekruse updated DRILL-2691:
---
Fix Version/s: (was: 1.0.0)
1.1.0
> 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.1.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] [Updated] (DRILL-2343) Create JDBC tracing proxy driver.
[ https://issues.apache.org/jira/browse/DRILL-2343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Barclay (Drill) updated DRILL-2343: -- Attachment: DRILL-2343.3.patch.txt > Create JDBC tracing proxy driver. > - > > Key: DRILL-2343 > URL: https://issues.apache.org/jira/browse/DRILL-2343 > Project: Apache Drill > Issue Type: New Feature > Components: Client - JDBC >Reporter: Daniel Barclay (Drill) >Assignee: Daniel Barclay (Drill) > Fix For: Future > > Attachments: DRILL-2343.3.patch.txt > > > Create JDBC driver that functions as proxy to Drill (or other) JDBC driver in > order to report calls made across the JDBC API. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-2343) Create JDBC tracing proxy driver.
[ https://issues.apache.org/jira/browse/DRILL-2343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Barclay (Drill) updated DRILL-2343: -- Attachment: (was: DRILL-2343.2.patch.txt) > Create JDBC tracing proxy driver. > - > > Key: DRILL-2343 > URL: https://issues.apache.org/jira/browse/DRILL-2343 > Project: Apache Drill > Issue Type: New Feature > Components: Client - JDBC >Reporter: Daniel Barclay (Drill) >Assignee: Daniel Barclay (Drill) > Fix For: Future > > Attachments: DRILL-2343.3.patch.txt > > > Create JDBC driver that functions as proxy to Drill (or other) JDBC driver in > order to report calls made across the JDBC API. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (DRILL-2249) Parquet reader hit IOBE when reading decimal type columns.
[
https://issues.apache.org/jira/browse/DRILL-2249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rahul Challapalli closed DRILL-2249.
Verified and added the below test case
Functional/Passing/ctas/ctas_t18_DRILL-2249.sql
> Parquet reader hit IOBE when reading decimal type columns.
> ---
>
> Key: DRILL-2249
> URL: https://issues.apache.org/jira/browse/DRILL-2249
> Project: Apache Drill
> Issue Type: Bug
> Components: Storage - Parquet, Storage - Writer
>Reporter: Jinfeng Ni
>Assignee: Steven Phillips
>
> On today's master branch:
> select commit_id from sys.version;
> ++
> | commit_id |
> ++
> | 4ed0a8d68ec5ef344fb54ff7c9d857f7f3f153aa |
> ++
> If I create a parquet file containing two decimal(10,2) columns as:
> {code}
> create table my_dec_table as select *, cast(o_totalprice as decimal(10,2))
> dec1, cast(o_totalprice as decimal(10,2)) dec2 from cp.`tpch/orders.parquet`;
> ++---+
> | Fragment | Number of records written |
> ++---+
> | 0_0 | 15000 |
> ++---+
> 1 row selected (1.977 seconds)
> {code}
> However, when I try to read from the new created parquet file, Drill report
> IOBE in parquet reader.
> {code}
> select * from my_dec_table;
> Query failed: Query stopped., index: 22531, length: 1 (expected: range(0,
> 22531)) [ ee35bc67-5c70-4677-bf7f-8db12e4a5491 on 10.250.0.8:31010 ]
> {code}
> The plan looks fine to me for this query:
> {code}
> xplain plan for select * from my_dec_table;
> +++
> |text|json|
> +++
> | 00-00Screen
> 00-01 Scan(groupscan=[ParquetGroupScan [entries=[ReadEntryWithPath
> [path=file:/Users/jni/work/data/tpcds/my_dec_table]],
> selectionRoot=/Users/jni/work/data/tpcds/my_dec_table, numFiles=1,
> columns=[`*`]]])
> {code}
> Here is part of the stack trace:
> {code}
> java.lang.IndexOutOfBoundsException: index: 22531, length: 1 (expected:
> range(0, 22531))
> 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.getByte(DrillBuf.java:673)
> ~[drill-java-exec-0.8.0-SNAPSHOT-rebuffed.jar:4.0.24.Final]
> at
> org.apache.drill.exec.store.parquet.columnreaders.FixedByteAlignedReader$DateReader.readIntLittleEndian(FixedByteAlignedReader.java:144)
> ~[drill-java-exec-0.8.0-SNAPSHOT-rebuffed.jar:0.8.0-SNAPSHOT]
> at
> org.apache.drill.exec.store.parquet.columnreaders.FixedByteAlignedReader...
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DRILL-1662) drillbit.sh stop should timeout
[ https://issues.apache.org/jira/browse/DRILL-1662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramana Inukonda Nagaraj updated DRILL-1662: --- Attachment: patch.diff Please find a patch with the fix. > 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 > > Attachments: patch.diff > > > 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-1942) Improve off-heap memory usage tracking
[ https://issues.apache.org/jira/browse/DRILL-1942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Westin updated DRILL-1942: Attachment: (was: DRILL-1942.patch) > Improve off-heap memory usage tracking > -- > > Key: DRILL-1942 > URL: https://issues.apache.org/jira/browse/DRILL-1942 > Project: Apache Drill > Issue Type: Improvement > Components: Execution - Relational Operators >Reporter: Chris Westin >Assignee: Chris Westin > Fix For: 1.0.0 > > Attachments: DRILL-1942.1.patch.txt > > > We're using a lot more memory than we think we should. We may be leaking it, > or not releasing it as soon as we could. > This is a call to come up with some improved tracking so that we can get > statistics out about exactly where we're using it, and whether or not we can > release it earlier. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-1942) Improve off-heap memory usage tracking
[ https://issues.apache.org/jira/browse/DRILL-1942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Westin updated DRILL-1942: Attachment: DRILL-1942.1.patch.txt > Improve off-heap memory usage tracking > -- > > Key: DRILL-1942 > URL: https://issues.apache.org/jira/browse/DRILL-1942 > Project: Apache Drill > Issue Type: Improvement > Components: Execution - Relational Operators >Reporter: Chris Westin >Assignee: Chris Westin > Fix For: 1.0.0 > > Attachments: DRILL-1942.1.patch.txt > > > We're using a lot more memory than we think we should. We may be leaking it, > or not releasing it as soon as we could. > This is a call to come up with some improved tracking so that we can get > statistics out about exactly where we're using it, and whether or not we can > release it earlier. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DRILL-1942) Improve off-heap memory usage tracking
[ https://issues.apache.org/jira/browse/DRILL-1942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14535459#comment-14535459 ] Chris Westin commented on DRILL-1942: - The script output and the above message says it created the review, but it didn't, and the file it attached here is empty. I'll hand upload a real patch file here, but I can't get review board to accept the file for the moment > Improve off-heap memory usage tracking > -- > > Key: DRILL-1942 > URL: https://issues.apache.org/jira/browse/DRILL-1942 > Project: Apache Drill > Issue Type: Improvement > Components: Execution - Relational Operators >Reporter: Chris Westin >Assignee: Chris Westin > Fix For: 1.0.0 > > Attachments: DRILL-1942.patch > > > We're using a lot more memory than we think we should. We may be leaking it, > or not releasing it as soon as we could. > This is a call to come up with some improved tracking so that we can get > statistics out about exactly where we're using it, and whether or not we can > release it earlier. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DRILL-2343) Create JDBC tracing proxy driver.
[ https://issues.apache.org/jira/browse/DRILL-2343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14535456#comment-14535456 ] Daniel Barclay (Drill) commented on DRILL-2343: --- Commit message/comment: DRILL-2343: Add tracing proxy JDBC driver for tracing JDBC method calls. Overview of org.apache.drill.jdbc.proxy classes/interfaces: Entry point: - TracingProxyDriver - Tracing proxy JDBC driver class. Class description Javadoc has usage instructions. Other core types: - ProxiesManager - creates and tracks java.lang.reflect.Proxy-based proxy objects - TracingInvocationHandler - java.lang.reflect.Proxy invocation handler; maps reflective/proxy invocations to InvocationReporter method call/return/throw event calls - InvocationReporter - defines method call/return/throw event calls - InvocationReporterImpl - implements rendering of method call/return/throw event calls (including rendering of parameter/return/exception values). - ProxySetupSQLException Unit tests: - TracingProxyDriverClassLoadingTest - test of loading proxied driver class - TracingProxyDriverTest - basic test of proxying (pass-through) and tracing output Other: - exec/jdbc-all/pom.xml - has change to keep TracingProxyDriver and depended-on classes in JDBC-all Jar file. > Create JDBC tracing proxy driver. > - > > Key: DRILL-2343 > URL: https://issues.apache.org/jira/browse/DRILL-2343 > Project: Apache Drill > Issue Type: New Feature > Components: Client - JDBC >Reporter: Daniel Barclay (Drill) >Assignee: Daniel Barclay (Drill) > Fix For: Future > > Attachments: DRILL-2343.2.patch.txt > > > Create JDBC driver that functions as proxy to Drill (or other) JDBC driver in > order to report calls made across the JDBC API. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-2343) Create JDBC tracing proxy driver.
[ https://issues.apache.org/jira/browse/DRILL-2343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Barclay (Drill) updated DRILL-2343: -- Attachment: DRILL-2343.2.patch.txt > Create JDBC tracing proxy driver. > - > > Key: DRILL-2343 > URL: https://issues.apache.org/jira/browse/DRILL-2343 > Project: Apache Drill > Issue Type: New Feature > Components: Client - JDBC >Reporter: Daniel Barclay (Drill) >Assignee: Daniel Barclay (Drill) > Fix For: Future > > Attachments: DRILL-2343.2.patch.txt > > > Create JDBC driver that functions as proxy to Drill (or other) JDBC driver in > order to report calls made across the JDBC API. -- 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=14535451#comment-14535451
]
Rahul Challapalli commented on DRILL-2408:
--
Verified!
> 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, DRILL-2408.8.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-2343) Create JDBC tracing proxy driver.
[ https://issues.apache.org/jira/browse/DRILL-2343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Barclay (Drill) updated DRILL-2343: -- Attachment: (was: DRILL-2343.1.patch.txt) > Create JDBC tracing proxy driver. > - > > Key: DRILL-2343 > URL: https://issues.apache.org/jira/browse/DRILL-2343 > Project: Apache Drill > Issue Type: New Feature > Components: Client - JDBC >Reporter: Daniel Barclay (Drill) >Assignee: Daniel Barclay (Drill) > Fix For: Future > > Attachments: DRILL-2343.2.patch.txt > > > Create JDBC driver that functions as proxy to Drill (or other) JDBC driver in > order to report calls made across the JDBC API. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (DRILL-1180) Case messes up the datatype returned by function surrounding it
[ https://issues.apache.org/jira/browse/DRILL-1180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramana Inukonda Nagaraj closed DRILL-1180. -- Verified as part of TPCH SF100 queries > Case messes up the datatype returned by function surrounding it > --- > > Key: DRILL-1180 > URL: https://issues.apache.org/jira/browse/DRILL-1180 > Project: Apache Drill > Issue Type: Bug >Reporter: Ramana Inukonda Nagaraj >Assignee: DrillCommitter >Priority: Critical > Fix For: 0.4.0 > > Attachments: DRILL-1180.patch > > > Hit this while investigating tpch data variation between postgres and drill > Simplified tpch14 to the following query: > select > sum(case > when l.L_RETURNFLAG like 'R%' > then l.l_extendedprice * (1 - l.l_discount) > else 0 > end) > from lineitem l; > returns bigint in the case of drill and double in the case of postgres. > Extendedprice and discount are double though. > Drill:507996494 > Postgres:507996454.406699 > However when the case is removed and we use an equivalent filter instead > drill and postgres return the same results: > select > sum(l.l_extendedprice * (1 - l.l_discount) > from lineitem l where l.L_RETURNFLAG like 'R%'; > Postgres: 507996454.406699 > Drill: 5.0799645440669966E8 > This would explain the data mismatch for both TPCH14 and 8 > git.commit.id.abbrev=e5c2da0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (DRILL-2453) hbase queries in certain env result in NPE at FragmentWritableBatch.getEmptyBatchWithSchema()
[
https://issues.apache.org/jira/browse/DRILL-2453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ramana Inukonda Nagaraj closed DRILL-2453.
--
Verified as working as of 7abd7cf4e3a6e67b4168d3d598ee01eb62e346e6
> hbase queries in certain env result in NPE at
> FragmentWritableBatch.getEmptyBatchWithSchema()
> -
>
> Key: DRILL-2453
> URL: https://issues.apache.org/jira/browse/DRILL-2453
> Project: Apache Drill
> Issue Type: Bug
> Components: Storage - HBase
>Affects Versions: 0.8.0
>Reporter: Ramana Inukonda Nagaraj
>Assignee: Venki Korukanti
>Priority: Critical
> Fix For: 0.8.0
>
> Attachments: DRILL-2453-1.patch
>
>
> Sounds similar to Drill-1932
> But seems to be from a different place.
> Stacktrace:
> {code}
> java.lang.NullPointerException: null
> at
> org.apache.drill.exec.record.FragmentWritableBatch.getEmptyBatchWithSchema(FragmentWritableBatch.java:86)
> ~[drill-java-exec-0.8.0-SNAPSHOT-rebuffed.jar:0.8.0-SNAPSHOT]
> at
> org.apache.drill.exec.physical.impl.partitionsender.PartitionSenderRootExec.sendEmptyBatch(PartitionSenderRootExec.java:276)
> ~[drill-java-exec-0.8.0-SNAPSHOT-rebuffed.j
> ar:0.8.0-SNAPSHOT]
> at
> org.apache.drill.exec.physical.impl.partitionsender.PartitionSenderRootExec.innerNext(PartitionSenderRootExec.java:133)
> ~[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:121)
> ~[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_51]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> [na:1.7.0_51]
> at java.lang.Thread.run(Thread.java:744) [na:1.7.0_51]
> 2015-03-13 13:41:50,740 [2afcb471-b3a1-f719-a4ce-bbd75c36637a:frag:2:2] ERROR
> o.a.drill.exec.ops.FragmentContext - Fragment Context received failure.
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DRILL-1942) Improve off-heap memory usage tracking
[ https://issues.apache.org/jira/browse/DRILL-1942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14535434#comment-14535434 ] Chris Westin commented on DRILL-1942: - Created reviewboard > Improve off-heap memory usage tracking > -- > > Key: DRILL-1942 > URL: https://issues.apache.org/jira/browse/DRILL-1942 > Project: Apache Drill > Issue Type: Improvement > Components: Execution - Relational Operators >Reporter: Chris Westin >Assignee: Chris Westin > Fix For: 1.0.0 > > Attachments: DRILL-1942.patch > > > We're using a lot more memory than we think we should. We may be leaking it, > or not releasing it as soon as we could. > This is a call to come up with some improved tracking so that we can get > statistics out about exactly where we're using it, and whether or not we can > release it earlier. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-1942) Improve off-heap memory usage tracking
[ https://issues.apache.org/jira/browse/DRILL-1942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Westin updated DRILL-1942: Attachment: DRILL-1942.patch > Improve off-heap memory usage tracking > -- > > Key: DRILL-1942 > URL: https://issues.apache.org/jira/browse/DRILL-1942 > Project: Apache Drill > Issue Type: Improvement > Components: Execution - Relational Operators >Reporter: Chris Westin >Assignee: Chris Westin > Fix For: 1.0.0 > > Attachments: DRILL-1942.patch > > > We're using a lot more memory than we think we should. We may be leaking it, > or not releasing it as soon as we could. > This is a call to come up with some improved tracking so that we can get > statistics out about exactly where we're using it, and whether or not we can > release it earlier. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DRILL-2985) NPE seen for project distinct values from CSV
[
https://issues.apache.org/jira/browse/DRILL-2985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14535423#comment-14535423
]
Khurram Faraaz commented on DRILL-2985:
---
This is a regression. I disabled the new text reader and I don't see the NPE,
the NPE is seen with the new text reader.
{code}
0: jdbc:drill:> alter session set `exec.storage.enable_new_text_reader` = false;
+++
| ok | summary |
+++
| true | exec.storage.enable_new_text_reader updated. |
+++
1 row selected (0.129 seconds)
{code}
We see proper message when new text reader is disabled.
{code}
0: jdbc:drill:> select distinct type from `airports.csv`;
Error: SYSTEM ERROR: Selected column(s) must have name 'columns' or must be
plain '*'
Fragment 0:0
[Error Id: a43e56d0-31f5-4aec-b881-9269080546dd on centos-04.qa.lab:31010]
(state=,code=0)
{code}
> NPE seen for project distinct values from CSV
> -
>
> Key: DRILL-2985
> URL: https://issues.apache.org/jira/browse/DRILL-2985
> Project: Apache Drill
> Issue Type: Bug
> Components: Storage - Text & CSV
>Affects Versions: 1.0.0
> Environment: d12bee05a8f6e974c70d5d2a94176b176d7dba5b | DRILL-2508:
> Added a wrapper class for OptionValue to include status Option status: BOOT,
> DEFAULT, CHANGED | 07.05.2015 @ 13:08:36 EDT
>Reporter: Khurram Faraaz
>Assignee: Steven Phillips
>
> I am seeing a NPE when we project distinct values. Test was run on 4 node
> cluster on CentOS.
> {code}
> 0: jdbc:drill:> select distinct type from `airports.csv`;
> Error: SYSTEM ERROR: null
> Fragment 0:0
> [Error Id: 9f6e6929-41f6-4821-8a31-8bd45143f3d1 on centos-01.qa.lab:31010]
> (state=,code=0)
> {code}
> Stacktrace from drillbit.log
> {code}
> 2015-05-07 20:03:21,790 [2ab43af5-b6a9-0578-c45b-454b1a1a7b35:frag:0:0] ERROR
> o.a.d.c.e.DrillRuntimeException - SYSTEM ERROR: null
> Fragment 0:0
> [Error Id: 9f6e6929-41f6-4821-8a31-8bd45143f3d1 on centos-01.qa.lab:31010]
> org.apache.drill.common.exceptions.UserException: SYSTEM ERROR: null
> Fragment 0:0
> [Error Id: 9f6e6929-41f6-4821-8a31-8bd45143f3d1 on centos-01.qa.lab:31010]
> at
> org.apache.drill.common.exceptions.UserException$Builder.build(UserException.java:465)
> ~[drill-common-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
> at
> org.apache.drill.exec.work.fragment.FragmentExecutor.sendFinalState(FragmentExecutor.java:262)
> [drill-java-exec-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
> at
> org.apache.drill.exec.work.fragment.FragmentExecutor.run(FragmentExecutor.java:232)
> [drill-java-exec-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
> at
> org.apache.drill.common.SelfCleaningRunnable.run(SelfCleaningRunnable.java:38)
> [drill-common-1.0.0-SNAPSHOT-rebuffed.jar:1.0.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.NullPointerException: null
> at
> org.apache.drill.exec.store.easy.text.compliant.CompliantTextRecordReader.cleanup(CompliantTextRecordReader.java:147)
> ~[drill-java-exec-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
> at
> org.apache.drill.exec.physical.impl.ScanBatch.(ScanBatch.java:104)
> ~[drill-java-exec-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
> at
> org.apache.drill.exec.store.dfs.easy.EasyFormatPlugin.getReaderBatch(EasyFormatPlugin.java:189)
> ~[drill-java-exec-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
> at
> org.apache.drill.exec.store.dfs.easy.EasyReaderBatchCreator.getBatch(EasyReaderBatchCreator.java:35)
> ~[drill-java-exec-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
> at
> org.apache.drill.exec.store.dfs.easy.EasyReaderBatchCreator.getBatch(EasyReaderBatchCreator.java:28)
> ~[drill-java-exec-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
> at
> org.apache.drill.exec.physical.impl.ImplCreator.getRecordBatch(ImplCreator.java:140)
> ~[drill-java-exec-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
> at
> org.apache.drill.exec.physical.impl.ImplCreator.getChildren(ImplCreator.java:163)
> ~[drill-java-exec-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
> at
> org.apache.drill.exec.physical.impl.ImplCreator.getRecordBatch(ImplCreator.java:121)
> ~[drill-java-exec-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
> at
> org.apache.drill.exec.physical.impl.ImplCreator.getChildren(ImplCreator.java:163)
> ~[drill-java-exec-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
> at
> org.apache.drill.exec.physical.impl.ImplCreator.getRecordBatc
[jira] [Updated] (DRILL-2985) REGRESSION : NPE seen for project distinct values from CSV
[
https://issues.apache.org/jira/browse/DRILL-2985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Khurram Faraaz updated DRILL-2985:
--
Summary: REGRESSION : NPE seen for project distinct values from CSV (was:
NPE seen for project distinct values from CSV)
> REGRESSION : NPE seen for project distinct values from CSV
> --
>
> Key: DRILL-2985
> URL: https://issues.apache.org/jira/browse/DRILL-2985
> Project: Apache Drill
> Issue Type: Bug
> Components: Storage - Text & CSV
>Affects Versions: 1.0.0
> Environment: d12bee05a8f6e974c70d5d2a94176b176d7dba5b | DRILL-2508:
> Added a wrapper class for OptionValue to include status Option status: BOOT,
> DEFAULT, CHANGED | 07.05.2015 @ 13:08:36 EDT
>Reporter: Khurram Faraaz
>Assignee: Steven Phillips
>
> I am seeing a NPE when we project distinct values. Test was run on 4 node
> cluster on CentOS.
> {code}
> 0: jdbc:drill:> select distinct type from `airports.csv`;
> Error: SYSTEM ERROR: null
> Fragment 0:0
> [Error Id: 9f6e6929-41f6-4821-8a31-8bd45143f3d1 on centos-01.qa.lab:31010]
> (state=,code=0)
> {code}
> Stacktrace from drillbit.log
> {code}
> 2015-05-07 20:03:21,790 [2ab43af5-b6a9-0578-c45b-454b1a1a7b35:frag:0:0] ERROR
> o.a.d.c.e.DrillRuntimeException - SYSTEM ERROR: null
> Fragment 0:0
> [Error Id: 9f6e6929-41f6-4821-8a31-8bd45143f3d1 on centos-01.qa.lab:31010]
> org.apache.drill.common.exceptions.UserException: SYSTEM ERROR: null
> Fragment 0:0
> [Error Id: 9f6e6929-41f6-4821-8a31-8bd45143f3d1 on centos-01.qa.lab:31010]
> at
> org.apache.drill.common.exceptions.UserException$Builder.build(UserException.java:465)
> ~[drill-common-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
> at
> org.apache.drill.exec.work.fragment.FragmentExecutor.sendFinalState(FragmentExecutor.java:262)
> [drill-java-exec-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
> at
> org.apache.drill.exec.work.fragment.FragmentExecutor.run(FragmentExecutor.java:232)
> [drill-java-exec-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
> at
> org.apache.drill.common.SelfCleaningRunnable.run(SelfCleaningRunnable.java:38)
> [drill-common-1.0.0-SNAPSHOT-rebuffed.jar:1.0.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.NullPointerException: null
> at
> org.apache.drill.exec.store.easy.text.compliant.CompliantTextRecordReader.cleanup(CompliantTextRecordReader.java:147)
> ~[drill-java-exec-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
> at
> org.apache.drill.exec.physical.impl.ScanBatch.(ScanBatch.java:104)
> ~[drill-java-exec-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
> at
> org.apache.drill.exec.store.dfs.easy.EasyFormatPlugin.getReaderBatch(EasyFormatPlugin.java:189)
> ~[drill-java-exec-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
> at
> org.apache.drill.exec.store.dfs.easy.EasyReaderBatchCreator.getBatch(EasyReaderBatchCreator.java:35)
> ~[drill-java-exec-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
> at
> org.apache.drill.exec.store.dfs.easy.EasyReaderBatchCreator.getBatch(EasyReaderBatchCreator.java:28)
> ~[drill-java-exec-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
> at
> org.apache.drill.exec.physical.impl.ImplCreator.getRecordBatch(ImplCreator.java:140)
> ~[drill-java-exec-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
> at
> org.apache.drill.exec.physical.impl.ImplCreator.getChildren(ImplCreator.java:163)
> ~[drill-java-exec-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
> at
> org.apache.drill.exec.physical.impl.ImplCreator.getRecordBatch(ImplCreator.java:121)
> ~[drill-java-exec-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
> at
> org.apache.drill.exec.physical.impl.ImplCreator.getChildren(ImplCreator.java:163)
> ~[drill-java-exec-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
> at
> org.apache.drill.exec.physical.impl.ImplCreator.getRecordBatch(ImplCreator.java:121)
> ~[drill-java-exec-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
> at
> org.apache.drill.exec.physical.impl.ImplCreator.getChildren(ImplCreator.java:163)
> ~[drill-java-exec-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
> at
> org.apache.drill.exec.physical.impl.ImplCreator.getRecordBatch(ImplCreator.java:121)
> ~[drill-java-exec-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
> at
> org.apache.drill.exec.physical.impl.ImplCreator.getChildren(ImplCreator.java:163)
> ~[drill-java-exec-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
> at
> org.apache.drill.exec.physical.impl.ImplCreator.getRoo
[jira] [Closed] (DRILL-1580) Count(*) on TPCDS JSON dataset (table store_sales) throws NullPointerException
[ https://issues.apache.org/jira/browse/DRILL-1580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhishek Girish closed DRILL-1580. -- > Count(*) on TPCDS JSON dataset (table store_sales) throws NullPointerException > -- > > Key: DRILL-1580 > URL: https://issues.apache.org/jira/browse/DRILL-1580 > Project: Apache Drill > Issue Type: Bug >Reporter: Abhishek Girish >Assignee: Jacques Nadeau > Labels: no_verified_test > Fix For: 0.7.0 > > > > select count(*) from store_sales; > Query failed: Failure while running fragment. Schema is currently null. You > must call buildSchema(SelectionVectorMode) before this container can return a > schema. [289a6c1c-46e9-469d-8a3b-a23292f608f7] > Error: exception while executing query: Failure while trying to get next > result batch. (state=,code=0) > Stack trace attached. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-1580) Count(*) on TPCDS JSON dataset (table store_sales) throws NullPointerException
[ https://issues.apache.org/jira/browse/DRILL-1580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhishek Girish updated DRILL-1580: --- Labels: no_verified_test (was: ) > Count(*) on TPCDS JSON dataset (table store_sales) throws NullPointerException > -- > > Key: DRILL-1580 > URL: https://issues.apache.org/jira/browse/DRILL-1580 > Project: Apache Drill > Issue Type: Bug >Reporter: Abhishek Girish >Assignee: Jacques Nadeau > Labels: no_verified_test > Fix For: 0.7.0 > > > > select count(*) from store_sales; > Query failed: Failure while running fragment. Schema is currently null. You > must call buildSchema(SelectionVectorMode) before this container can return a > schema. [289a6c1c-46e9-469d-8a3b-a23292f608f7] > Error: exception while executing query: Failure while trying to get next > result batch. (state=,code=0) > Stack trace attached. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
