[jira] [Assigned] (DRILL-6452) document steps to execute SQL queries from Postman (chrome extension) on Drill

[Pritesh Maker (JIRA)]

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

Pritesh Maker reassigned DRILL-6452:


Assignee: Khurram Faraaz

> document steps to execute SQL queries from Postman (chrome extension) on Drill
> --
>
> Key: DRILL-6452
> URL: https://issues.apache.org/jira/browse/DRILL-6452
> Project: Apache Drill
>  Issue Type: Bug
>  Components: Documentation
>Affects Versions: 1.14.0
>Reporter: Khurram Faraaz
>Assignee: Khurram Faraaz
>Priority: Minor
>
> We need documentation to list the steps with screen shots about executing SQL 
> queries from Postman (chrome extension) on Drill.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (DRILL-6452) document steps to execute SQL queries from Postman (chrome extension) on Drill

[Pritesh Maker (JIRA)]

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

Pritesh Maker updated DRILL-6452:
-
Issue Type: Task  (was: Bug)

> document steps to execute SQL queries from Postman (chrome extension) on Drill
> --
>
> Key: DRILL-6452
> URL: https://issues.apache.org/jira/browse/DRILL-6452
> Project: Apache Drill
>  Issue Type: Task
>  Components: Documentation
>Affects Versions: 1.14.0
>Reporter: Khurram Faraaz
>Assignee: Khurram Faraaz
>Priority: Minor
>
> We need documentation to list the steps with screen shots about executing SQL 
> queries from Postman (chrome extension) on Drill.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (DRILL-6453) TPC-DS query 72 has regressed

[Pritesh Maker (JIRA)]

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

Pritesh Maker reassigned DRILL-6453:


Assignee: Volodymyr Vysotskyi

> TPC-DS query 72 has regressed
> -
>
> Key: DRILL-6453
> URL: https://issues.apache.org/jira/browse/DRILL-6453
> Project: Apache Drill
>  Issue Type: Bug
>  Components: Execution - Flow
>Affects Versions: 1.14.0
>Reporter: Khurram Faraaz
>Assignee: Volodymyr Vysotskyi
>Priority: Critical
> Attachments: 24f75b18-014a-fb58-21d2-baeab5c3352c.sys.drill
>
>
> TPC-DS query 72 seems to have regressed, query profile for the case where it 
> Canceled after 2 hours on Drill 1.14.0 is attached here.
> {noformat}
> On, Drill 1.14.0-SNAPSHOT 
> commit : 931b43e (TPC-DS query 72 executed successfully on this commit, took 
> around 55 seconds to execute)
> SF1 parquet data on 4 nodes; 
> planner.memory.max_query_memory_per_node = 10737418240. 
> drill.exec.hashagg.fallback.enabled = true
> TPC-DS query 72 executed successfully & took 47 seconds to complete execution.
> {noformat}
> {noformat}
> TPC-DS data in the below run has date values stored as DATE datatype and not 
> VARCHAR type
> On, Drill 1.14.0-SNAPSHOT
> commit : 82e1a12
> SF1 parquet data on 4 nodes; 
> planner.memory.max_query_memory_per_node = 10737418240. 
> drill.exec.hashagg.fallback.enabled = true
> and
> alter system set `exec.hashjoin.num_partitions` = 1;
> TPC-DS query 72 executed for 2 hrs and 11 mins and did not complete, I had to 
> Cancel it by stopping the Foreman drillbit.
> As a result several minor fragments are reported to be in 
> CANCELLATION_REQUESTED state on UI.
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (DRILL-6453) TPC-DS query 72 has regressed

[Khurram Faraaz (JIRA)]

Khurram Faraaz created DRILL-6453:
-

 Summary: TPC-DS query 72 has regressed
 Key: DRILL-6453
 URL: https://issues.apache.org/jira/browse/DRILL-6453
 Project: Apache Drill
  Issue Type: Bug
  Components: Execution - Flow
Affects Versions: 1.14.0
Reporter: Khurram Faraaz
 Attachments: 24f75b18-014a-fb58-21d2-baeab5c3352c.sys.drill

TPC-DS query 72 seems to have regressed, query profile for the case where it 
Canceled after 2 hours on Drill 1.14.0 is attached here.

{noformat}
On, Drill 1.14.0-SNAPSHOT 
commit : 931b43e (TPC-DS query 72 executed successfully on this commit, took 
around 55 seconds to execute)
SF1 parquet data on 4 nodes; 
planner.memory.max_query_memory_per_node = 10737418240. 
drill.exec.hashagg.fallback.enabled = true

TPC-DS query 72 executed successfully & took 47 seconds to complete execution.
{noformat}


{noformat}
TPC-DS data in the below run has date values stored as DATE datatype and not 
VARCHAR type

On, Drill 1.14.0-SNAPSHOT
commit : 82e1a12
SF1 parquet data on 4 nodes; 
planner.memory.max_query_memory_per_node = 10737418240. 
drill.exec.hashagg.fallback.enabled = true
and
alter system set `exec.hashjoin.num_partitions` = 1;

TPC-DS query 72 executed for 2 hrs and 11 mins and did not complete, I had to 
Cancel it by stopping the Foreman drillbit.
As a result several minor fragments are reported to be in 
CANCELLATION_REQUESTED state on UI.
{noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (DRILL-6452) document steps to execute SQL queries from Postman (chrome extension) on Drill

[Khurram Faraaz (JIRA)]

Khurram Faraaz created DRILL-6452:
-

 Summary: document steps to execute SQL queries from Postman 
(chrome extension) on Drill
 Key: DRILL-6452
 URL: https://issues.apache.org/jira/browse/DRILL-6452
 Project: Apache Drill
  Issue Type: Bug
  Components: Documentation
Affects Versions: 1.14.0
Reporter: Khurram Faraaz


We need documentation to list the steps with screen shots about executing SQL 
queries from Postman (chrome extension) on Drill.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (DRILL-6212) A simple join is recursing too deep in planning and eventually throwing stack overflow.

[Pritesh Maker (JIRA)]

[ 
https://issues.apache.org/jira/browse/DRILL-6212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16494535#comment-16494535
 ] 

Pritesh Maker commented on DRILL-6212:
--

[~cshi] not sure if you are actively working on this. If not I suggest we 
reassign this one - [~vvysotskyi] can you pick this up?

 

Also, I am assuming the fix is required in Calcite (CALCITE-2223) ... is that 
correct?

> A simple join is recursing too deep in planning and eventually throwing stack 
> overflow.
> ---
>
> Key: DRILL-6212
> URL: https://issues.apache.org/jira/browse/DRILL-6212
> Project: Apache Drill
>  Issue Type: Bug
>  Components: Query Planning & Optimization
>Affects Versions: 1.12.0
>Reporter: Hanumath Rao Maduri
>Assignee: Chunhui Shi
>Priority: Critical
> Fix For: 1.14.0
>
>
> Create two views using following statements.
> {code}
> create view v1 as select cast(greeting as int) f from 
> dfs.`/home/mapr/data/json/temp.json`;
> create view v2 as select cast(greeting as int) f from 
> dfs.`/home/mapr/data/json/temp.json`;
> {code}
> Executing the following join query produces a stack overflow during the 
> planning phase.
> {code}
> select t1.f from dfs.tmp.v1 as t inner join dfs.tmp.v2 as t1 on cast(t.f as 
> int) = cast(t1.f as int) and cast(t.f as int) = 10 and cast(t1.f as int) = 10;
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (DRILL-5365) FileNotFoundException when reading a parquet file

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/DRILL-5365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16494526#comment-16494526
 ] 

ASF GitHub Bot commented on DRILL-5365:
---

ilooner commented on a change in pull request #796: DRILL-5365: DrillFileSystem 
setConf in constructor. DrillFileSystem c…
URL: https://github.com/apache/drill/pull/796#discussion_r191614286
 
 

 ##
 File path: 
exec/java-exec/src/main/java/org/apache/drill/exec/store/dfs/FileSystemPlugin.java
 ##
 @@ -74,6 +74,7 @@ public FileSystemPlugin(FileSystemConfig config, 
DrillbitContext context, String
   fsConf.set(s, config.config.get(s));
 }
   }
+  fsConf.set("fs.default.name", config.connection);
 
 Review comment:
   Doing a quick google it looks like you are correct. **fs.default.name** is 
deprecated and we should use **fs.defaultFS** instead 
https://stackoverflow.com/questions/30480847/difference-between-fs-defaultfs-and-fs-default-name?utm_medium=organic&utm_source=google_rich_qa&utm_campaign=google_rich_qa.
 Also hortonworks dropped **fs.default.name** from Ambari a long time ago so we 
should be safe https://issues.apache.org/jira/browse/AMBARI-2789 .


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> FileNotFoundException when reading a parquet file
> -
>
> Key: DRILL-5365
> URL: https://issues.apache.org/jira/browse/DRILL-5365
> Project: Apache Drill
>  Issue Type: Bug
>  Components: Storage - Hive
>Affects Versions: 1.10.0
>Reporter: Chun Chang
>Assignee: Timothy Farkas
>Priority: Major
> Fix For: 1.14.0
>
>
> The parquet file is generated through the following CTAS.
> To reproduce the issue: 1) two or more nodes cluster; 2) enable 
> impersonation; 3) set "fs.default.name": "file:///" in hive storage plugin; 
> 4) restart drillbits; 5) as a regular user, on node A, drop the table/file; 
> 6) ctas from a large enough hive table as source to recreate the table/file; 
> 7) query the table from node A should work; 8) query from node B as same user 
> should reproduce the issue.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (DRILL-5365) FileNotFoundException when reading a parquet file

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/DRILL-5365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16494527#comment-16494527
 ] 

ASF GitHub Bot commented on DRILL-5365:
---

ilooner commented on a change in pull request #796: DRILL-5365: DrillFileSystem 
setConf in constructor. DrillFileSystem c…
URL: https://github.com/apache/drill/pull/796#discussion_r191614286
 
 

 ##
 File path: 
exec/java-exec/src/main/java/org/apache/drill/exec/store/dfs/FileSystemPlugin.java
 ##
 @@ -74,6 +74,7 @@ public FileSystemPlugin(FileSystemConfig config, 
DrillbitContext context, String
   fsConf.set(s, config.config.get(s));
 }
   }
+  fsConf.set("fs.default.name", config.connection);
 
 Review comment:
   Doing a quick google it looks like you are correct. **fs.default.name** is 
deprecated and we should use **fs.defaultFS** instead 
https://stackoverflow.com/questions/30480847/difference-between-fs-defaultfs-and-fs-default-name?utm_medium=organic&utm_source=google_rich_qa&utm_campaign=google_rich_qa.
 Also hortonworks dropped **fs.default.name** from Ambari a long time ago so we 
should be safe https://issues.apache.org/jira/browse/AMBARI-2789 .
   
   I will remove this extra configuration.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> FileNotFoundException when reading a parquet file
> -
>
> Key: DRILL-5365
> URL: https://issues.apache.org/jira/browse/DRILL-5365
> Project: Apache Drill
>  Issue Type: Bug
>  Components: Storage - Hive
>Affects Versions: 1.10.0
>Reporter: Chun Chang
>Assignee: Timothy Farkas
>Priority: Major
> Fix For: 1.14.0
>
>
> The parquet file is generated through the following CTAS.
> To reproduce the issue: 1) two or more nodes cluster; 2) enable 
> impersonation; 3) set "fs.default.name": "file:///" in hive storage plugin; 
> 4) restart drillbits; 5) as a regular user, on node A, drop the table/file; 
> 6) ctas from a large enough hive table as source to recreate the table/file; 
> 7) query the table from node A should work; 8) query from node B as same user 
> should reproduce the issue.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (DRILL-5365) FileNotFoundException when reading a parquet file

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/DRILL-5365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16494521#comment-16494521
 ] 

ASF GitHub Bot commented on DRILL-5365:
---

ilooner commented on issue #796: DRILL-5365: DrillFileSystem setConf in 
constructor. DrillFileSystem c…
URL: https://github.com/apache/drill/pull/796#issuecomment-392991258
 
 
   Continuing this PR here https://github.com/apache/drill/pull/1296 . I will 
provide responses to all existing comments here, all new comments should be 
directed at https://github.com/apache/drill/pull/1296 .


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> FileNotFoundException when reading a parquet file
> -
>
> Key: DRILL-5365
> URL: https://issues.apache.org/jira/browse/DRILL-5365
> Project: Apache Drill
>  Issue Type: Bug
>  Components: Storage - Hive
>Affects Versions: 1.10.0
>Reporter: Chun Chang
>Assignee: Timothy Farkas
>Priority: Major
> Fix For: 1.14.0
>
>
> The parquet file is generated through the following CTAS.
> To reproduce the issue: 1) two or more nodes cluster; 2) enable 
> impersonation; 3) set "fs.default.name": "file:///" in hive storage plugin; 
> 4) restart drillbits; 5) as a regular user, on node A, drop the table/file; 
> 6) ctas from a large enough hive table as source to recreate the table/file; 
> 7) query the table from node A should work; 8) query from node B as same user 
> should reproduce the issue.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (DRILL-5365) FileNotFoundException when reading a parquet file

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/DRILL-5365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16494520#comment-16494520
 ] 

ASF GitHub Bot commented on DRILL-5365:
---

ilooner opened a new pull request #1296: DRILL-5365: DrillFileSystem setConf in 
constructor. DrillFileSystem c…
URL: https://github.com/apache/drill/pull/1296
 
 
   …ould be created based on provided URI.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> FileNotFoundException when reading a parquet file
> -
>
> Key: DRILL-5365
> URL: https://issues.apache.org/jira/browse/DRILL-5365
> Project: Apache Drill
>  Issue Type: Bug
>  Components: Storage - Hive
>Affects Versions: 1.10.0
>Reporter: Chun Chang
>Assignee: Timothy Farkas
>Priority: Major
> Fix For: 1.14.0
>
>
> The parquet file is generated through the following CTAS.
> To reproduce the issue: 1) two or more nodes cluster; 2) enable 
> impersonation; 3) set "fs.default.name": "file:///" in hive storage plugin; 
> 4) restart drillbits; 5) as a regular user, on node A, drop the table/file; 
> 6) ctas from a large enough hive table as source to recreate the table/file; 
> 7) query the table from node A should work; 8) query from node B as same user 
> should reproduce the issue.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (DRILL-5365) FileNotFoundException when reading a parquet file

[Timothy Farkas (JIRA)]

[ 
https://issues.apache.org/jira/browse/DRILL-5365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16494517#comment-16494517
 ] 

Timothy Farkas commented on DRILL-5365:
---

[~cshi] I'll take this PR to completion. I'll keep the original commit 
attributed to you.

> FileNotFoundException when reading a parquet file
> -
>
> Key: DRILL-5365
> URL: https://issues.apache.org/jira/browse/DRILL-5365
> Project: Apache Drill
>  Issue Type: Bug
>  Components: Storage - Hive
>Affects Versions: 1.10.0
>Reporter: Chun Chang
>Assignee: Timothy Farkas
>Priority: Major
> Fix For: 1.14.0
>
>
> The parquet file is generated through the following CTAS.
> To reproduce the issue: 1) two or more nodes cluster; 2) enable 
> impersonation; 3) set "fs.default.name": "file:///" in hive storage plugin; 
> 4) restart drillbits; 5) as a regular user, on node A, drop the table/file; 
> 6) ctas from a large enough hive table as source to recreate the table/file; 
> 7) query the table from node A should work; 8) query from node B as same user 
> should reproduce the issue.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (DRILL-5365) FileNotFoundException when reading a parquet file

[Timothy Farkas (JIRA)]

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

Timothy Farkas reassigned DRILL-5365:
-

Assignee: Timothy Farkas  (was: Chunhui Shi)

> FileNotFoundException when reading a parquet file
> -
>
> Key: DRILL-5365
> URL: https://issues.apache.org/jira/browse/DRILL-5365
> Project: Apache Drill
>  Issue Type: Bug
>  Components: Storage - Hive
>Affects Versions: 1.10.0
>Reporter: Chun Chang
>Assignee: Timothy Farkas
>Priority: Major
> Fix For: 1.14.0
>
>
> The parquet file is generated through the following CTAS.
> To reproduce the issue: 1) two or more nodes cluster; 2) enable 
> impersonation; 3) set "fs.default.name": "file:///" in hive storage plugin; 
> 4) restart drillbits; 5) as a regular user, on node A, drop the table/file; 
> 6) ctas from a large enough hive table as source to recreate the table/file; 
> 7) query the table from node A should work; 8) query from node B as same user 
> should reproduce the issue.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (DRILL-6415) Unit test TestGracefulShutdown.testRestApiShutdown times out

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/DRILL-6415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16494452#comment-16494452
 ] 

ASF GitHub Bot commented on DRILL-6415:
---

ilooner commented on issue #1281: DRILL-6415: Fixed 
TestGracefulShutdown.TestRestApi test from timing out
URL: https://github.com/apache/drill/pull/1281#issuecomment-392982276
 
 
   @parthchandra Could this be merged soon since this fixes a build failure?


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Unit test TestGracefulShutdown.testRestApiShutdown times out
> 
>
> Key: DRILL-6415
> URL: https://issues.apache.org/jira/browse/DRILL-6415
> Project: Apache Drill
>  Issue Type: Bug
>  Components: Tools, Build & Test
>Reporter: Abhishek Girish
>Assignee: Venkata Jyothsna Donapati
>Priority: Major
>  Labels: ready-to-commit
> Fix For: 1.14.0
>
>
> {code}
> 16:03:40.415 [main] ERROR org.apache.drill.TestReporter - Test Failed (d: 
> -18.3 KiB(72.9 KiB), h: -335.3 MiB(1.3 GiB), nh: 1.1 MiB(335.9 MiB)): 
> testRestApiShutdown(org.apache.drill.test.TestGracefulShutdown)
> org.junit.runners.model.TestTimedOutException: test timed out after 18 
> milliseconds
>   at sun.misc.Unsafe.park(Native Method) ~[na:1.8.0_161]
>   at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) 
> ~[na:1.8.0_161]
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitUninterruptibly(AbstractQueuedSynchronizer.java:1976)
>  ~[na:1.8.0_161]
>   at 
> org.apache.drill.exec.work.WorkManager.waitToExit(WorkManager.java:203) 
> ~[classes/:na]
>   at org.apache.drill.exec.server.Drillbit.close(Drillbit.java:242) 
> ~[classes/:na]
>   at 
> org.apache.drill.test.ClusterFixture.safeClose(ClusterFixture.java:454) 
> ~[test-classes/:1.14.0-SNAPSHOT]
>   at org.apache.drill.test.ClusterFixture.close(ClusterFixture.java:405) 
> ~[test-classes/:1.14.0-SNAPSHOT]
>   at 
> org.apache.drill.test.TestGracefulShutdown.testRestApiShutdown(TestGracefulShutdown.java:294)
>  ~[test-classes/:1.14.0-SNAPSHOT]
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
> ~[na:1.8.0_161]
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) 
> ~[na:1.8.0_161]
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  ~[na:1.8.0_161]
>   at java.lang.reflect.Method.invoke(Method.java:498) ~[na:1.8.0_161]
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>  ~[junit-4.12.jar:4.12]
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>  ~[junit-4.12.jar:4.12]
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>  ~[junit-4.12.jar:4.12]
>   at 
> mockit.integration.junit4.internal.JUnit4TestRunnerDecorator.executeTestMethod(JUnit4TestRunnerDecorator.java:154)
>  ~[jmockit-1.39.jar:1.39]
>   at 
> mockit.integration.junit4.internal.JUnit4TestRunnerDecorator.invokeExplosively(JUnit4TestRunnerDecorator.java:70)
>  ~[jmockit-1.39.jar:1.39]
>   at 
> mockit.integration.junit4.internal.FakeFrameworkMethod.invokeExplosively(FakeFrameworkMethod.java:34)
>  ~[jmockit-1.39.jar:1.39]
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java)
>  ~[junit-4.12.jar:4.12]
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>  ~[junit-4.12.jar:4.12]
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) 
> ~[junit-4.12.jar:4.12]
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) 
> ~[junit-4.12.jar:4.12]
>   at 
> org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:298)
>  ~[junit-4.12.jar:4.12]
>   at 
> org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:292)
>  ~[junit-4.12.jar:4.12]
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
> ~[na:1.8.0_161]
>   at java.lang.Thread.run(Thread.java:748) ~[na:1.8.0_161]
> {code}
> {code}
> testRestApiShutdown(org.apache.drill.test.TestGracefulShutdown)  Time 
> elapsed: 180.028 sec  <<< ERROR!
> org.junit.runners.model.TestTimedOutException: test timed out after 18 
> milliseconds
>   at sun.misc.Unsafe.park(Native Method)
>   at java.util.co

[jira] [Updated] (DRILL-6415) Unit test TestGracefulShutdown.testRestApiShutdown times out

[Timothy Farkas (JIRA)]

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

Timothy Farkas updated DRILL-6415:
--
Labels: ready-to-commit  (was: )

> Unit test TestGracefulShutdown.testRestApiShutdown times out
> 
>
> Key: DRILL-6415
> URL: https://issues.apache.org/jira/browse/DRILL-6415
> Project: Apache Drill
>  Issue Type: Bug
>  Components: Tools, Build & Test
>Reporter: Abhishek Girish
>Assignee: Venkata Jyothsna Donapati
>Priority: Major
>  Labels: ready-to-commit
> Fix For: 1.14.0
>
>
> {code}
> 16:03:40.415 [main] ERROR org.apache.drill.TestReporter - Test Failed (d: 
> -18.3 KiB(72.9 KiB), h: -335.3 MiB(1.3 GiB), nh: 1.1 MiB(335.9 MiB)): 
> testRestApiShutdown(org.apache.drill.test.TestGracefulShutdown)
> org.junit.runners.model.TestTimedOutException: test timed out after 18 
> milliseconds
>   at sun.misc.Unsafe.park(Native Method) ~[na:1.8.0_161]
>   at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) 
> ~[na:1.8.0_161]
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitUninterruptibly(AbstractQueuedSynchronizer.java:1976)
>  ~[na:1.8.0_161]
>   at 
> org.apache.drill.exec.work.WorkManager.waitToExit(WorkManager.java:203) 
> ~[classes/:na]
>   at org.apache.drill.exec.server.Drillbit.close(Drillbit.java:242) 
> ~[classes/:na]
>   at 
> org.apache.drill.test.ClusterFixture.safeClose(ClusterFixture.java:454) 
> ~[test-classes/:1.14.0-SNAPSHOT]
>   at org.apache.drill.test.ClusterFixture.close(ClusterFixture.java:405) 
> ~[test-classes/:1.14.0-SNAPSHOT]
>   at 
> org.apache.drill.test.TestGracefulShutdown.testRestApiShutdown(TestGracefulShutdown.java:294)
>  ~[test-classes/:1.14.0-SNAPSHOT]
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
> ~[na:1.8.0_161]
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) 
> ~[na:1.8.0_161]
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  ~[na:1.8.0_161]
>   at java.lang.reflect.Method.invoke(Method.java:498) ~[na:1.8.0_161]
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>  ~[junit-4.12.jar:4.12]
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>  ~[junit-4.12.jar:4.12]
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>  ~[junit-4.12.jar:4.12]
>   at 
> mockit.integration.junit4.internal.JUnit4TestRunnerDecorator.executeTestMethod(JUnit4TestRunnerDecorator.java:154)
>  ~[jmockit-1.39.jar:1.39]
>   at 
> mockit.integration.junit4.internal.JUnit4TestRunnerDecorator.invokeExplosively(JUnit4TestRunnerDecorator.java:70)
>  ~[jmockit-1.39.jar:1.39]
>   at 
> mockit.integration.junit4.internal.FakeFrameworkMethod.invokeExplosively(FakeFrameworkMethod.java:34)
>  ~[jmockit-1.39.jar:1.39]
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java)
>  ~[junit-4.12.jar:4.12]
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>  ~[junit-4.12.jar:4.12]
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) 
> ~[junit-4.12.jar:4.12]
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) 
> ~[junit-4.12.jar:4.12]
>   at 
> org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:298)
>  ~[junit-4.12.jar:4.12]
>   at 
> org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:292)
>  ~[junit-4.12.jar:4.12]
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
> ~[na:1.8.0_161]
>   at java.lang.Thread.run(Thread.java:748) ~[na:1.8.0_161]
> {code}
> {code}
> testRestApiShutdown(org.apache.drill.test.TestGracefulShutdown)  Time 
> elapsed: 180.028 sec  <<< ERROR!
> org.junit.runners.model.TestTimedOutException: test timed out after 18 
> milliseconds
>   at sun.misc.Unsafe.park(Native Method)
>   at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitUninterruptibly(AbstractQueuedSynchronizer.java:1976)
>   at 
> org.apache.drill.exec.work.WorkManager.waitToExit(WorkManager.java:203)
>   at org.apache.drill.exec.server.Drillbit.close(Drillbit.java:242)
>   at 
> org.apache.drill.test.ClusterFixture.safeClose(ClusterFixture.java:454)
>   at org.apache.drill.test.ClusterFixture.close(ClusterFixture.java:405)
>   at 
> org.apache.drill.test.TestGracefulShutdown.testRestApiShutdo

[jira] [Commented] (DRILL-6415) Unit test TestGracefulShutdown.testRestApiShutdown times out

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/DRILL-6415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16494450#comment-16494450
 ] 

ASF GitHub Bot commented on DRILL-6415:
---

ilooner commented on issue #1281: DRILL-6415: Fixed 
TestGracefulShutdown.TestRestApi test from timing out
URL: https://github.com/apache/drill/pull/1281#issuecomment-392981748
 
 
   LGMT +1. Thanks for addressing all the comments! I'll mark as ready to 
commit.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Unit test TestGracefulShutdown.testRestApiShutdown times out
> 
>
> Key: DRILL-6415
> URL: https://issues.apache.org/jira/browse/DRILL-6415
> Project: Apache Drill
>  Issue Type: Bug
>  Components: Tools, Build & Test
>Reporter: Abhishek Girish
>Assignee: Venkata Jyothsna Donapati
>Priority: Major
> Fix For: 1.14.0
>
>
> {code}
> 16:03:40.415 [main] ERROR org.apache.drill.TestReporter - Test Failed (d: 
> -18.3 KiB(72.9 KiB), h: -335.3 MiB(1.3 GiB), nh: 1.1 MiB(335.9 MiB)): 
> testRestApiShutdown(org.apache.drill.test.TestGracefulShutdown)
> org.junit.runners.model.TestTimedOutException: test timed out after 18 
> milliseconds
>   at sun.misc.Unsafe.park(Native Method) ~[na:1.8.0_161]
>   at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) 
> ~[na:1.8.0_161]
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitUninterruptibly(AbstractQueuedSynchronizer.java:1976)
>  ~[na:1.8.0_161]
>   at 
> org.apache.drill.exec.work.WorkManager.waitToExit(WorkManager.java:203) 
> ~[classes/:na]
>   at org.apache.drill.exec.server.Drillbit.close(Drillbit.java:242) 
> ~[classes/:na]
>   at 
> org.apache.drill.test.ClusterFixture.safeClose(ClusterFixture.java:454) 
> ~[test-classes/:1.14.0-SNAPSHOT]
>   at org.apache.drill.test.ClusterFixture.close(ClusterFixture.java:405) 
> ~[test-classes/:1.14.0-SNAPSHOT]
>   at 
> org.apache.drill.test.TestGracefulShutdown.testRestApiShutdown(TestGracefulShutdown.java:294)
>  ~[test-classes/:1.14.0-SNAPSHOT]
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
> ~[na:1.8.0_161]
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) 
> ~[na:1.8.0_161]
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  ~[na:1.8.0_161]
>   at java.lang.reflect.Method.invoke(Method.java:498) ~[na:1.8.0_161]
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>  ~[junit-4.12.jar:4.12]
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>  ~[junit-4.12.jar:4.12]
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>  ~[junit-4.12.jar:4.12]
>   at 
> mockit.integration.junit4.internal.JUnit4TestRunnerDecorator.executeTestMethod(JUnit4TestRunnerDecorator.java:154)
>  ~[jmockit-1.39.jar:1.39]
>   at 
> mockit.integration.junit4.internal.JUnit4TestRunnerDecorator.invokeExplosively(JUnit4TestRunnerDecorator.java:70)
>  ~[jmockit-1.39.jar:1.39]
>   at 
> mockit.integration.junit4.internal.FakeFrameworkMethod.invokeExplosively(FakeFrameworkMethod.java:34)
>  ~[jmockit-1.39.jar:1.39]
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java)
>  ~[junit-4.12.jar:4.12]
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>  ~[junit-4.12.jar:4.12]
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) 
> ~[junit-4.12.jar:4.12]
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) 
> ~[junit-4.12.jar:4.12]
>   at 
> org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:298)
>  ~[junit-4.12.jar:4.12]
>   at 
> org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:292)
>  ~[junit-4.12.jar:4.12]
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
> ~[na:1.8.0_161]
>   at java.lang.Thread.run(Thread.java:748) ~[na:1.8.0_161]
> {code}
> {code}
> testRestApiShutdown(org.apache.drill.test.TestGracefulShutdown)  Time 
> elapsed: 180.028 sec  <<< ERROR!
> org.junit.runners.model.TestTimedOutException: test timed out after 18 
> milliseconds
>   at sun.misc.Unsafe.park(Native Method)
>   at java.util.concurrent.locks.LockSupport.park(L

[jira] [Commented] (DRILL-6415) Unit test TestGracefulShutdown.testRestApiShutdown times out

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/DRILL-6415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16494402#comment-16494402
 ] 

ASF GitHub Bot commented on DRILL-6415:
---

dvjyothsna commented on issue #1281: DRILL-6415: Fixed 
TestGracefulShutdown.TestRestApi test from timing out
URL: https://github.com/apache/drill/pull/1281#issuecomment-392971014
 
 
   @ilooner I have addressed all the review comments. Can you please do another 
round of review. Thank you. 


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Unit test TestGracefulShutdown.testRestApiShutdown times out
> 
>
> Key: DRILL-6415
> URL: https://issues.apache.org/jira/browse/DRILL-6415
> Project: Apache Drill
>  Issue Type: Bug
>  Components: Tools, Build & Test
>Reporter: Abhishek Girish
>Assignee: Venkata Jyothsna Donapati
>Priority: Major
> Fix For: 1.14.0
>
>
> {code}
> 16:03:40.415 [main] ERROR org.apache.drill.TestReporter - Test Failed (d: 
> -18.3 KiB(72.9 KiB), h: -335.3 MiB(1.3 GiB), nh: 1.1 MiB(335.9 MiB)): 
> testRestApiShutdown(org.apache.drill.test.TestGracefulShutdown)
> org.junit.runners.model.TestTimedOutException: test timed out after 18 
> milliseconds
>   at sun.misc.Unsafe.park(Native Method) ~[na:1.8.0_161]
>   at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) 
> ~[na:1.8.0_161]
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitUninterruptibly(AbstractQueuedSynchronizer.java:1976)
>  ~[na:1.8.0_161]
>   at 
> org.apache.drill.exec.work.WorkManager.waitToExit(WorkManager.java:203) 
> ~[classes/:na]
>   at org.apache.drill.exec.server.Drillbit.close(Drillbit.java:242) 
> ~[classes/:na]
>   at 
> org.apache.drill.test.ClusterFixture.safeClose(ClusterFixture.java:454) 
> ~[test-classes/:1.14.0-SNAPSHOT]
>   at org.apache.drill.test.ClusterFixture.close(ClusterFixture.java:405) 
> ~[test-classes/:1.14.0-SNAPSHOT]
>   at 
> org.apache.drill.test.TestGracefulShutdown.testRestApiShutdown(TestGracefulShutdown.java:294)
>  ~[test-classes/:1.14.0-SNAPSHOT]
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
> ~[na:1.8.0_161]
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) 
> ~[na:1.8.0_161]
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  ~[na:1.8.0_161]
>   at java.lang.reflect.Method.invoke(Method.java:498) ~[na:1.8.0_161]
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>  ~[junit-4.12.jar:4.12]
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>  ~[junit-4.12.jar:4.12]
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>  ~[junit-4.12.jar:4.12]
>   at 
> mockit.integration.junit4.internal.JUnit4TestRunnerDecorator.executeTestMethod(JUnit4TestRunnerDecorator.java:154)
>  ~[jmockit-1.39.jar:1.39]
>   at 
> mockit.integration.junit4.internal.JUnit4TestRunnerDecorator.invokeExplosively(JUnit4TestRunnerDecorator.java:70)
>  ~[jmockit-1.39.jar:1.39]
>   at 
> mockit.integration.junit4.internal.FakeFrameworkMethod.invokeExplosively(FakeFrameworkMethod.java:34)
>  ~[jmockit-1.39.jar:1.39]
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java)
>  ~[junit-4.12.jar:4.12]
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>  ~[junit-4.12.jar:4.12]
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) 
> ~[junit-4.12.jar:4.12]
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) 
> ~[junit-4.12.jar:4.12]
>   at 
> org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:298)
>  ~[junit-4.12.jar:4.12]
>   at 
> org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:292)
>  ~[junit-4.12.jar:4.12]
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
> ~[na:1.8.0_161]
>   at java.lang.Thread.run(Thread.java:748) ~[na:1.8.0_161]
> {code}
> {code}
> testRestApiShutdown(org.apache.drill.test.TestGracefulShutdown)  Time 
> elapsed: 180.028 sec  <<< ERROR!
> org.junit.runners.model.TestTimedOutException: test timed out after 18 
> milliseconds
>   at sun.misc.Unsafe.park(Native Method)
>   at java.util.concu

[jira] [Created] (DRILL-6451) Support SSL on different UserServer Port

[Sorabh Hamirwasia (JIRA)]

Sorabh Hamirwasia created DRILL-6451:


 Summary: Support SSL on different UserServer Port
 Key: DRILL-6451
 URL: https://issues.apache.org/jira/browse/DRILL-6451
 Project: Apache Drill
  Issue Type: Task
  Components: Security
Reporter: Sorabh Hamirwasia
 Fix For: Future


Currently Drill's implementation of SSL between DrillClient and Drillbit is 
using the same user port which is used for non SSL traffic. If a setup is 
needed to support SSL encryption with Plain authentication and SASL encryption 
with Kerberos then that won't be possible. But with a separate port for SSL we 
can support above setup such that on SSL port encryption will always be using 
SSL and with any type of authentication. Whereas on non-SSL port things will 
work only with SASL (encryption + authentication).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (DRILL-6373) Refactor the Result Set Loader to prepare for Union, List support

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/DRILL-6373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16494285#comment-16494285
 ] 

ASF GitHub Bot commented on DRILL-6373:
---

paul-rogers commented on issue #1244: DRILL-6373: Refactor Result Set Loader 
for Union, List support
URL: https://github.com/apache/drill/pull/1244#issuecomment-392947880
 
 
   Thanks @ppadma! If you can explain how to reproduce the issue without using 
the full functional tests, I can take a look.
   
   In case it leads to anything... Earlier changes around `MaterializedField` 
did try to keep the various views of data in sync. The map's 
`MaterializedField` is supposed to contain, as children, all the map members. 
This means that changes to any map field requires a matching change to the 
children. This didn't always happen, leading to bugs that earlier PRs attempted 
to fix. Not sure if that has an impact here.
   
   The other question is whether the partition sender is the only code that 
calls the `clone()` method. Do we have unit tests for that method?
   
   Is there some interaction in cloning that reaches back into the original 
child list? A quick scan of the code didn't suggest any, which is why I wonder 
if the change occurs in another thread; perhaps triggered as a result of recent 
fixes in the partitioned sender.
   
   Please let us know what you find, then I'd be happy to fix it.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Refactor the Result Set Loader to prepare for Union, List support
> -
>
> Key: DRILL-6373
> URL: https://issues.apache.org/jira/browse/DRILL-6373
> Project: Apache Drill
>  Issue Type: Improvement
>Affects Versions: 1.13.0
>Reporter: Paul Rogers
>Assignee: Paul Rogers
>Priority: Major
> Fix For: 1.14.0
>
>
> As the next step in merging the "batch sizing" enhancements, refactor the 
> {{ResultSetLoader}} and related classes to prepare for Union and List 
> support. This fix follows the refactoring of the column accessors for the 
> same purpose. Actual Union and List support is to follow in a separate PR.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (DRILL-6373) Refactor the Result Set Loader to prepare for Union, List support

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/DRILL-6373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16494211#comment-16494211
 ] 

ASF GitHub Bot commented on DRILL-6373:
---

ppadma commented on issue #1244: DRILL-6373: Refactor Result Set Loader for 
Union, List support
URL: https://github.com/apache/drill/pull/1244#issuecomment-392933598
 
 
   @paul-rogers @Ben-Zvi I ran the tests and got the same failure. Seems like a 
day one issue. I am not sure why it happens with your PR consistently. I will 
try to chase it down.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Refactor the Result Set Loader to prepare for Union, List support
> -
>
> Key: DRILL-6373
> URL: https://issues.apache.org/jira/browse/DRILL-6373
> Project: Apache Drill
>  Issue Type: Improvement
>Affects Versions: 1.13.0
>Reporter: Paul Rogers
>Assignee: Paul Rogers
>Priority: Major
> Fix For: 1.14.0
>
>
> As the next step in merging the "batch sizing" enhancements, refactor the 
> {{ResultSetLoader}} and related classes to prepare for Union and List 
> support. This fix follows the refactoring of the column accessors for the 
> same purpose. Actual Union and List support is to follow in a separate PR.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (DRILL-6447) Unsupported Operation when reading parquet data

[salim achouche (JIRA)]

[ 
https://issues.apache.org/jira/browse/DRILL-6447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16494167#comment-16494167
 ] 

salim achouche commented on DRILL-6447:
---

I have fixed this issue but [~vrozov] indicated he incorporated the fix as part 
of the Parquet upgrade. [~vrozov] can you please close my PR when this issue 
has been fixed.

> Unsupported Operation when reading parquet data
> ---
>
> Key: DRILL-6447
> URL: https://issues.apache.org/jira/browse/DRILL-6447
> Project: Apache Drill
>  Issue Type: Bug
>  Components: Storage - Parquet
>Affects Versions: 1.14.0
>Reporter: salim achouche
>Assignee: Vlad Rozov
>Priority: Major
> Fix For: 1.14.0
>
>   Original Estimate: 2h
>  Remaining Estimate: 2h
>
> An exception is thrown when reading Parquet data.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (DRILL-6447) Unsupported Operation when reading parquet data

[salim achouche (JIRA)]

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

salim achouche reassigned DRILL-6447:
-

Assignee: Vlad Rozov  (was: salim achouche)

> Unsupported Operation when reading parquet data
> ---
>
> Key: DRILL-6447
> URL: https://issues.apache.org/jira/browse/DRILL-6447
> Project: Apache Drill
>  Issue Type: Bug
>  Components: Storage - Parquet
>Affects Versions: 1.14.0
>Reporter: salim achouche
>Assignee: Vlad Rozov
>Priority: Major
> Fix For: 1.14.0
>
>   Original Estimate: 2h
>  Remaining Estimate: 2h
>
> An exception is thrown when reading Parquet data.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (DRILL-6353) Upgrade Parquet MR dependencies

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/DRILL-6353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16494161#comment-16494161
 ] 

ASF GitHub Bot commented on DRILL-6353:
---

vrozov commented on issue #1259: DRILL-6353: Upgrade Parquet MR dependencies
URL: https://github.com/apache/drill/pull/1259#issuecomment-392923265
 
 
   The fix for PARQUET-77 is included into 1.10.0, 1.9.0 and 1.8.3 as it is not 
specific for Apache Drill.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Upgrade Parquet MR dependencies
> ---
>
> Key: DRILL-6353
> URL: https://issues.apache.org/jira/browse/DRILL-6353
> Project: Apache Drill
>  Issue Type: Task
>Reporter: Vlad Rozov
>Assignee: Vlad Rozov
>Priority: Major
> Fix For: 1.14.0
>
>
> Upgrade from a custom build {{1.8.1-drill-r0}} to Apache release {{1.10.0}}.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (DRILL-6447) Unsupported Operation when reading parquet data

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/DRILL-6447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16494149#comment-16494149
 ] 

ASF GitHub Bot commented on DRILL-6447:
---

vrozov commented on a change in pull request #1291: DRILL-6447: Fixed a sanity 
check condition
URL: https://github.com/apache/drill/pull/1291#discussion_r191050730
 
 

 ##
 File path: 
exec/java-exec/src/main/java/org/apache/drill/exec/store/parquet/columnreaders/PageReader.java
 ##
 @@ -445,8 +445,8 @@ public void clear(){
* @throws IOException An IO related condition
*/
   void resetDefinitionLevelReader(int skipCount) throws IOException {
-if (parentColumnReader.columnDescriptor.getMaxDefinitionLevel() != 0) {
-  throw new UnsupportedOperationException("Unsupoorted Operation");
+if (parentColumnReader.columnDescriptor.getMaxDefinitionLevel() > 1) {
 
 Review comment:
   This is already part of Parquet version upgrade (see PR #1259), no need to 
fix it.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Unsupported Operation when reading parquet data
> ---
>
> Key: DRILL-6447
> URL: https://issues.apache.org/jira/browse/DRILL-6447
> Project: Apache Drill
>  Issue Type: Bug
>  Components: Storage - Parquet
>Affects Versions: 1.14.0
>Reporter: salim achouche
>Assignee: salim achouche
>Priority: Major
> Fix For: 1.14.0
>
>   Original Estimate: 2h
>  Remaining Estimate: 2h
>
> An exception is thrown when reading Parquet data.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (DRILL-6415) Unit test TestGracefulShutdown.testRestApiShutdown times out

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/DRILL-6415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16494131#comment-16494131
 ] 

ASF GitHub Bot commented on DRILL-6415:
---

ilooner commented on issue #1281: DRILL-6415: Fixed 
TestGracefulShutdown.TestRestApi test from timing out
URL: https://github.com/apache/drill/pull/1281#issuecomment-392917048
 
 
   @dvjyothsna let us know when you are ready for another round of review.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Unit test TestGracefulShutdown.testRestApiShutdown times out
> 
>
> Key: DRILL-6415
> URL: https://issues.apache.org/jira/browse/DRILL-6415
> Project: Apache Drill
>  Issue Type: Bug
>  Components: Tools, Build & Test
>Reporter: Abhishek Girish
>Assignee: Venkata Jyothsna Donapati
>Priority: Major
> Fix For: 1.14.0
>
>
> {code}
> 16:03:40.415 [main] ERROR org.apache.drill.TestReporter - Test Failed (d: 
> -18.3 KiB(72.9 KiB), h: -335.3 MiB(1.3 GiB), nh: 1.1 MiB(335.9 MiB)): 
> testRestApiShutdown(org.apache.drill.test.TestGracefulShutdown)
> org.junit.runners.model.TestTimedOutException: test timed out after 18 
> milliseconds
>   at sun.misc.Unsafe.park(Native Method) ~[na:1.8.0_161]
>   at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) 
> ~[na:1.8.0_161]
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitUninterruptibly(AbstractQueuedSynchronizer.java:1976)
>  ~[na:1.8.0_161]
>   at 
> org.apache.drill.exec.work.WorkManager.waitToExit(WorkManager.java:203) 
> ~[classes/:na]
>   at org.apache.drill.exec.server.Drillbit.close(Drillbit.java:242) 
> ~[classes/:na]
>   at 
> org.apache.drill.test.ClusterFixture.safeClose(ClusterFixture.java:454) 
> ~[test-classes/:1.14.0-SNAPSHOT]
>   at org.apache.drill.test.ClusterFixture.close(ClusterFixture.java:405) 
> ~[test-classes/:1.14.0-SNAPSHOT]
>   at 
> org.apache.drill.test.TestGracefulShutdown.testRestApiShutdown(TestGracefulShutdown.java:294)
>  ~[test-classes/:1.14.0-SNAPSHOT]
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
> ~[na:1.8.0_161]
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) 
> ~[na:1.8.0_161]
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  ~[na:1.8.0_161]
>   at java.lang.reflect.Method.invoke(Method.java:498) ~[na:1.8.0_161]
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>  ~[junit-4.12.jar:4.12]
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>  ~[junit-4.12.jar:4.12]
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>  ~[junit-4.12.jar:4.12]
>   at 
> mockit.integration.junit4.internal.JUnit4TestRunnerDecorator.executeTestMethod(JUnit4TestRunnerDecorator.java:154)
>  ~[jmockit-1.39.jar:1.39]
>   at 
> mockit.integration.junit4.internal.JUnit4TestRunnerDecorator.invokeExplosively(JUnit4TestRunnerDecorator.java:70)
>  ~[jmockit-1.39.jar:1.39]
>   at 
> mockit.integration.junit4.internal.FakeFrameworkMethod.invokeExplosively(FakeFrameworkMethod.java:34)
>  ~[jmockit-1.39.jar:1.39]
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java)
>  ~[junit-4.12.jar:4.12]
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>  ~[junit-4.12.jar:4.12]
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) 
> ~[junit-4.12.jar:4.12]
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) 
> ~[junit-4.12.jar:4.12]
>   at 
> org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:298)
>  ~[junit-4.12.jar:4.12]
>   at 
> org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:292)
>  ~[junit-4.12.jar:4.12]
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
> ~[na:1.8.0_161]
>   at java.lang.Thread.run(Thread.java:748) ~[na:1.8.0_161]
> {code}
> {code}
> testRestApiShutdown(org.apache.drill.test.TestGracefulShutdown)  Time 
> elapsed: 180.028 sec  <<< ERROR!
> org.junit.runners.model.TestTimedOutException: test timed out after 18 
> milliseconds
>   at sun.misc.Unsafe.park(Native Method)
>   at java.util.concurrent.locks.LockSupport.park(LockSuppo

[jira] [Commented] (DRILL-6449) Coordination issue between drillbits

[Pritesh Maker (JIRA)]

[ 
https://issues.apache.org/jira/browse/DRILL-6449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16494075#comment-16494075
 ] 

Pritesh Maker commented on DRILL-6449:
--

[~jaydlowrider] could you provide some steps to reproduce this issue (maybe 
attach some sample data files and logs)?

> Coordination issue between drillbits
> 
>
> Key: DRILL-6449
> URL: https://issues.apache.org/jira/browse/DRILL-6449
> Project: Apache Drill
>  Issue Type: Bug
>  Components: Functions - Drill
>Affects Versions: 1.13.0
> Environment: My POC info:
>  * 2 EC2 "r4.xlarge" with 30G of memory
>  * both are running zookeeper for load distribution 
>  * both are running drillbits.
>  * Storage
>  ** S3, dfs 
>  * Connection drivers: JDBC
>  * File Types/info: Json, max size between: 7MB - 75MB, and around 2200 
> different filles 
>  
>Reporter: Melvin Ramos
>Priority: Major
>
> hello
> We are evaluating apache drill 1.13.0 to be used on our data lake initiative.
>  
> Problem:
> I was able to select data when I ran small (around 3-50 files) query data 
> which is fine, but when I collapse all on month (2200 different json files) I 
> get into problems.
> on initial run it looks like its doing its work, but after executing the 
> actual work, both drillbits seems to wait on each other and see when they are 
> done, and nothing returns on my SQL analyzer query (Dbeaver)
>  
> Here are last few lines after the run.
> Drill Bit 1
>  
> {code:java}
> // code placeholder
> long_value: 380172
> }
> wait_nanos: 42213101
> }
> start_time: 1527341819358
> end_time: 1527341823288
> memory_used: 0
> max_memory_used: 5997952
> endpoint {
> address: "ip-10-0-2-209.us-west-2.compute.internal"
> user_port: 31010
> control_port: 31011
> data_port: 31012
> version: "1.13.0"
> state: ONLINE
> }
> }
> handle {
> query_id {
> part1: 2663488914051308194
> part2: -2037774217156077667
> }
> major_fragment_id: 1
> minor_fragment_id: 4
> }
> 2018-05-26 13:37:03,290 [BitServer-9] DEBUG 
> o.a.d.exec.work.foreman.QueryManager - Foreman is still waiting for 
> completion message from 1 nodes containing 4 fragments
> {code}
>  
> Drill Bit 2
>  
> {code:java}
> // code placeholder
> al.config.Limit
> 2018-05-26 13:37:03,197 [24f69d0e-3938-1aa2-e3b8-5f2565f6579d:frag:1:7] DEBUG 
> o.a.d.exec.ops.OperatorContextImpl - Closing context for 
> org.apache.drill.exec.physical.config.SelectionVectorRemover
> 2018-05-26 13:37:03,197 [24f69d0e-3938-1aa2-e3b8-5f2565f6579d:frag:1:7] DEBUG 
> o.a.d.exec.ops.OperatorContextImpl - Closing context for 
> org.apache.drill.exec.physical.config.SingleSender
> 2018-05-26 13:37:03,197 [24f69d0e-3938-1aa2-e3b8-5f2565f6579d:frag:1:7] INFO 
> o.a.d.e.w.fragment.FragmentExecutor - 
> 24f69d0e-3938-1aa2-e3b8-5f2565f6579d:1:7: State change requested RUNNING --> 
> FINISHED
> 2018-05-26 13:37:03,198 [24f69d0e-3938-1aa2-e3b8-5f2565f6579d:frag:1:7] INFO 
> o.a.d.e.w.f.FragmentStatusReporter - 
> 24f69d0e-3938-1aa2-e3b8-5f2565f6579d:1:7: State to report: FINISHED
> 2018-05-26 13:37:03,198 [24f69d0e-3938-1aa2-e3b8-5f2565f6579d:frag:1:7] DEBUG 
> o.a.d.e.w.f.FragmentStatusReporter - Closing 
> org.apache.drill.exec.work.fragment.FragmentStatusReporter@2552ae4c
> 2018-05-26 13:37:03,198 [drill-executor-3] INFO 
> o.apache.drill.exec.work.WorkManager - Waiting for 0 queries to complete 
> before shutting down
> 2018-05-26 13:37:03,199 [drill-executor-3] INFO 
> o.apache.drill.exec.work.WorkManager - Waiting for 1 running fragments to 
> complete before shutting down
> 2018-05-26 13:37:03,199 [drill-executor-3] INFO 
> o.apache.drill.exec.work.WorkManager - New Fragments or queries are added 
> while drillbit is Shutting down
> 2018-05-26 13:37:03,287 [24f69d0e-3938-1aa2-e3b8-5f2565f6579d:frag:1:4] DEBUG 
> o.a.d.e.physical.impl.BaseRootExec - closed operator 793318686
> 2018-05-26 13:37:03,287 [24f69d0e-3938-1aa2-e3b8-5f2565f6579d:frag:1:4] DEBUG 
> o.a.d.exec.ops.OperatorContextImpl - Closing context for 
> org.apache.drill.exec.store.dfs.easy.EasySubScan
> 2018-05-26 13:37:03,287 [24f69d0e-3938-1aa2-e3b8-5f2565f6579d:frag:1:4] DEBUG 
> o.a.d.exec.ops.OperatorContextImpl - Closing context for 
> org.apache.drill.exec.physical.config.Limit
> 2018-05-26 13:37:03,287 [24f69d0e-3938-1aa2-e3b8-5f2565f6579d:frag:1:4] DEBUG 
> o.a.d.exec.ops.OperatorContextImpl - Closing context for 
> org.apache.drill.exec.physical.config.SelectionVectorRemover
> 2018-05-26 13:37:03,287 [24f69d0e-3938-1aa2-e3b8-5f2565f6579d:frag:1:4] DEBUG 
> o.a.d.exec.ops.OperatorContextImpl - Closing context for 
> org.apache.drill.exec.physical.config.SingleSender
> 2018-05-26 13:37:03,288 [24f69d0e-3938-1aa2-e3b8-5f2565f6579d:frag:1:4] INFO 
> o.a.d.e.w.fragment.FragmentExecutor - 
> 24f69d0e-3938-1aa2-e3b8-5f2565f6579d:1:4: State change requested RUNNING --> 
>

[jira] [Commented] (DRILL-6450) Visualized plans for profiles querying JDBC sources is broken

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/DRILL-6450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16494042#comment-16494042
 ] 

ASF GitHub Bot commented on DRILL-6450:
---

kkhatua commented on issue #1295: DRILL-6450: Visualized plans for profiles 
querying JDBC sources is broken
URL: https://github.com/apache/drill/pull/1295#issuecomment-392892045
 
 
   @amansinha100  can you do a review for this small PR?


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Visualized plans for profiles querying JDBC sources is broken
> -
>
> Key: DRILL-6450
> URL: https://issues.apache.org/jira/browse/DRILL-6450
> Project: Apache Drill
>  Issue Type: Bug
>  Components: Query Planning & Optimization
>Affects Versions: 1.13.0
>Reporter: Kunal Khatua
>Assignee: Kunal Khatua
>Priority: Major
> Fix For: 1.14.0
>
>
> When viewing a profile for a query against a JDBC source, the visualized plan 
> is not rendered. This is because the generated SQL pushed down to the JDBC 
> source has a line break injected just before the {{FROM}} clause.
> The workaround is to strip away any injected newlines at least for the SQL 
> defined in the text plan, so that the backend Javascript can render it 
> correctly.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (DRILL-6450) Visualized plans for profiles querying JDBC sources is broken

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/DRILL-6450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16494040#comment-16494040
 ] 

ASF GitHub Bot commented on DRILL-6450:
---

kkhatua commented on issue #1295: DRILL-6450: Visualized plans for profiles 
querying JDBC sources is broken
URL: https://github.com/apache/drill/pull/1295#issuecomment-392891908
 
 
   **Before:** 
   
![image](https://user-images.githubusercontent.com/4335237/40678366-44ab78f6-6335-11e8-8266-67dee8b968d4.png)
   
   
   **After:**
   
![image](https://user-images.githubusercontent.com/4335237/40678388-4dfd2bde-6335-11e8-8354-e41407bdf0ae.png)
   
   
![image](https://user-images.githubusercontent.com/4335237/40678399-52472172-6335-11e8-9921-0c8e7ab28afe.png)
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Visualized plans for profiles querying JDBC sources is broken
> -
>
> Key: DRILL-6450
> URL: https://issues.apache.org/jira/browse/DRILL-6450
> Project: Apache Drill
>  Issue Type: Bug
>  Components: Query Planning & Optimization
>Affects Versions: 1.13.0
>Reporter: Kunal Khatua
>Assignee: Kunal Khatua
>Priority: Major
> Fix For: 1.14.0
>
>
> When viewing a profile for a query against a JDBC source, the visualized plan 
> is not rendered. This is because the generated SQL pushed down to the JDBC 
> source has a line break injected just before the {{FROM}} clause.
> The workaround is to strip away any injected newlines at least for the SQL 
> defined in the text plan, so that the backend Javascript can render it 
> correctly.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (DRILL-6450) Visualized plans for profiles querying JDBC sources is broken

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/DRILL-6450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16494041#comment-16494041
 ] 

ASF GitHub Bot commented on DRILL-6450:
---

kkhatua commented on issue #1295: DRILL-6450: Visualized plans for profiles 
querying JDBC sources is broken
URL: https://github.com/apache/drill/pull/1295#issuecomment-392892045
 
 
   @amansinha100  can you review this for this small PR?


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Visualized plans for profiles querying JDBC sources is broken
> -
>
> Key: DRILL-6450
> URL: https://issues.apache.org/jira/browse/DRILL-6450
> Project: Apache Drill
>  Issue Type: Bug
>  Components: Query Planning & Optimization
>Affects Versions: 1.13.0
>Reporter: Kunal Khatua
>Assignee: Kunal Khatua
>Priority: Major
> Fix For: 1.14.0
>
>
> When viewing a profile for a query against a JDBC source, the visualized plan 
> is not rendered. This is because the generated SQL pushed down to the JDBC 
> source has a line break injected just before the {{FROM}} clause.
> The workaround is to strip away any injected newlines at least for the SQL 
> defined in the text plan, so that the backend Javascript can render it 
> correctly.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (DRILL-6450) Visualized plans for profiles querying JDBC sources is broken

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/DRILL-6450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16494039#comment-16494039
 ] 

ASF GitHub Bot commented on DRILL-6450:
---

kkhatua opened a new pull request #1295: DRILL-6450: Visualized plans for 
profiles querying JDBC sources is broken
URL: https://github.com/apache/drill/pull/1295
 
 
   When viewing a profile for a query against a JDBC source, the visualized 
plan is not rendered. This is because the generated SQL pushed down to the JDBC 
source has a line break injected just before the FROM clause.
   
   The workaround is to strip away any injected newlines ('\\n') at least for 
the SQL defined in the text plan, so that the backend Javascript can render it 
correctly.
   In addition, any single line comments are also removed, but any block 
comments (i.e. /* .. */ ) are retained as they might carry hints.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Visualized plans for profiles querying JDBC sources is broken
> -
>
> Key: DRILL-6450
> URL: https://issues.apache.org/jira/browse/DRILL-6450
> Project: Apache Drill
>  Issue Type: Bug
>  Components: Query Planning & Optimization
>Affects Versions: 1.13.0
>Reporter: Kunal Khatua
>Assignee: Kunal Khatua
>Priority: Major
> Fix For: 1.14.0
>
>
> When viewing a profile for a query against a JDBC source, the visualized plan 
> is not rendered. This is because the generated SQL pushed down to the JDBC 
> source has a line break injected just before the {{FROM}} clause.
> The workaround is to strip away any injected newlines at least for the SQL 
> defined in the text plan, so that the backend Javascript can render it 
> correctly.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (DRILL-6450) Visualized plans for profiles querying JDBC sources is broken

[Kunal Khatua (JIRA)]

Kunal Khatua created DRILL-6450:
---

 Summary: Visualized plans for profiles querying JDBC sources is 
broken
 Key: DRILL-6450
 URL: https://issues.apache.org/jira/browse/DRILL-6450
 Project: Apache Drill
  Issue Type: Bug
  Components: Query Planning & Optimization
Affects Versions: 1.13.0
Reporter: Kunal Khatua
Assignee: Kunal Khatua
 Fix For: 1.14.0


When viewing a profile for a query against a JDBC source, the visualized plan 
is not rendered. This is because the generated SQL pushed down to the JDBC 
source has a line break injected just before the {{FROM}} clause.

The workaround is to strip away any injected newlines at least for the SQL 
defined in the text plan, so that the backend Javascript can render it 
correctly.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (DRILL-6353) Upgrade Parquet MR dependencies

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/DRILL-6353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16494012#comment-16494012
 ] 

ASF GitHub Bot commented on DRILL-6353:
---

parthchandra commented on issue #1259: DRILL-6353: Upgrade Parquet MR 
dependencies
URL: https://github.com/apache/drill/pull/1259#issuecomment-392885535
 
 
   The fix for the stats was part of a big commit to add support for
   ByteBuffers in Parquet (PARQUET-77
   ; commit 6b605a4
   
).
   See the included commit 7bc2a4d
   

   which
   was to fix the overwriting of stats.
   
   
   
   On Thu, May 24, 2018 at 6:55 PM, Vlad Rozov 
   wrote:
   
   > *@vrozov* commented on this pull request.
   > --
   >
   > In exec/java-exec/src/test/java/org/apache/drill/exec/store/parquet/
   > TestParquetMetadataCache.java
   > :
   >
   > > @@ -737,6 +738,7 @@ public void testBooleanPartitionPruning() throws 
Exception {
   >  }
   >}
   >
   > +  @Ignore
   >
   > It will be good if you can point to JIRA with the fix that Drill uses to
   > correct statistics. Without JIRA it is not clear what particular fix is
   > used by Drill to workaround bugs in how parquet library handles statistics
   > and for what data types.
   >
   > —
   > You are receiving this because you were mentioned.
   > Reply to this email directly, view it on GitHub
   > , or mute
   > the thread
   > 

   > .
   >
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Upgrade Parquet MR dependencies
> ---
>
> Key: DRILL-6353
> URL: https://issues.apache.org/jira/browse/DRILL-6353
> Project: Apache Drill
>  Issue Type: Task
>Reporter: Vlad Rozov
>Assignee: Vlad Rozov
>Priority: Major
> Fix For: 1.14.0
>
>
> Upgrade from a custom build {{1.8.1-drill-r0}} to Apache release {{1.10.0}}.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (DRILL-4364) Image Metadata Format Plugin

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/DRILL-4364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16493779#comment-16493779
 ] 

ASF GitHub Bot commented on DRILL-4364:
---

nagix commented on issue #367: DRILL-4364: Image Metadata Format Plugin
URL: https://github.com/apache/drill/pull/367#issuecomment-392837595
 
 
   @cgivre I have fixed the conflict and squashed the commit.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Image Metadata Format Plugin
> 
>
> Key: DRILL-4364
> URL: https://issues.apache.org/jira/browse/DRILL-4364
> Project: Apache Drill
>  Issue Type: New Feature
>  Components: Storage - Other
>Reporter: Akihiko Kusanagi
>Assignee: Akihiko Kusanagi
>Priority: Major
>  Labels: doc-impacting
> Fix For: 1.14.0
>
>
> Support querying of metadata in various image formats. This plugin leverages 
> [metadata-extractor|https://github.com/drewnoakes/metadata-extractor]. This 
> plugin is especially useful when querying on a large number of image files 
> stored in a distributed file system without building metadata repository in 
> advance.
> This plugin supports the following file formats.
>  * JPEG, TIFF, PSD, PNG, BMP, GIF, ICO, PCX, WAV, AVI, WebP, MOV, MP4, EPS
>  * Camera Raw: ARW (Sony), CRW/CR2 (Canon), NEF (Nikon), ORF (Olympus), RAF 
> (FujiFilm), RW2 (Panasonic), RWL (Leica), SRW (Samsung), X3F (Foveon)
> This plugin enables to read the following metadata.
>  * Exif, IPTC, XMP, JFIF / JFXX, ICC Profiles, Photoshop fields, PNG 
> properties, BMP properties, GIF properties, ICO properties, PCX properties, 
> WAV properties, AVI properties, WebP properties, QuickTime properties, MP4 
> properties, EPS properties
> Since each type of metadata has a different set of fields, the plugin returns 
> a set of commonly-used fields such as the image width, height and bits per 
> pixels for ease of use.
> *Examples:*
> Querying on a JPEG file with the property descriptive: true
> {noformat}
> 0: jdbc:drill:zk=local> select FileName, * from 
> dfs.`4349313028_f69ffa0257_o.jpg`;
> +--+--+--+++-+--+--+---++---+--+--++---++-+-+--+--+--++--+-+---+---+--+-+--+
> | FileName | FileSize | FileDateTime | Format | PixelWidth | PixelHeight | 
> BitsPerPixel | DPIWidth | DPIHeight | Orientaion | ColorMode | HasAlpha | 
> Duration | VideoCodec | FrameRate | AudioCodec | AudioSampleSize | 
> AudioSampleRate | JPEG | JFIF | ExifIFD0 | ExifSubIFD | Interoperability | 
> GPS | ExifThumbnail | Photoshop | IPTC | Huffman | FileType |
> +--+--+--+++-+--+--+---++---+--+--++---++-+-+--+--+--++--+-+---+---+--+-+--+
> | 4349313028_f69ffa0257_o.jpg | 257213 bytes | Fri Mar 09 12:09:34 +08:00 
> 2018 | JPEG | 1199 | 800 | 24 | 96 | 96 | Unknown (0) | RGB | false | 
> 00:00:00 | Unknown | 0 | Unknown | 0 | 0 | 
> {"CompressionType":"Baseline","DataPrecision":"8 bits","ImageHeight":"800 
> pixels","ImageWidth":"1199 pixels","NumberOfComponents":"3","Component1":"Y 
> component: Quantization table 0, Sampling factors 2 horiz/2 
> vert","Component2":"Cb component: Quantization table 1, Sampling factors 1 
> horiz/1 vert","Component3":"Cr component: Quantization table 1, Sampling 
> factors 1 horiz/1 vert"} | 
> {"Version":"1.1","ResolutionUnits":"inch","XResolution":"96 
> dots","YResolution":"96 
> dots","ThumbnailWidthPixels":"0","ThumbnailHeightPixels":"0"} | 
> {"Software":"Picasa 3.0"} | 
> {"ExifVersion":"2.10","UniqueImageID":"d65e93b836d15a0c5e041e6b7258c76e"} | 
> {"InteroperabilityIndex":"Unknown ()","InteroperabilityVersion":"1.00"} | 
> {"GPSVersionID":".022","GPSLatitudeRef":"N","GPSLatitude":"47° 32' 
> 15.98\"","GPSLongitudeRef":"W","GPSLongitude":"-122° 2' 
> 6.37\"","GPSAltitudeRef":"Sea level","GPSAltitude":"0 metres"} | 
> {"Compression":"JPEG (old-style)","XResolution":"72 dots per 
> inch","YResolution":"72 dots per 
> inch","ResolutionUnit":"Inch","ThumbnailOffset":"414 
> bytes","ThumbnailLength":"7213 bytes"} | {} | 
> {"Keywords":"135;2002;issaquah;police car;wa;wash

[jira] [Commented] (DRILL-6416) Unit test TestTpchDistributedConcurrent.testConcurrentQueries fails with AssertionError

[Vitalii Diravka (JIRA)]

[ 
https://issues.apache.org/jira/browse/DRILL-6416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16493439#comment-16493439
 ] 

Vitalii Diravka commented on DRILL-6416:


I have verified the case from description and the above cases mentioned by me 
and found that they are resolved in DRILL-6435.
[~vrozov] Could you please close this ticket?

> Unit test TestTpchDistributedConcurrent.testConcurrentQueries fails with 
> AssertionError
> ---
>
> Key: DRILL-6416
> URL: https://issues.apache.org/jira/browse/DRILL-6416
> Project: Apache Drill
>  Issue Type: Bug
>  Components: Tools, Build & Test
>Reporter: Abhishek Girish
>Assignee: Vlad Rozov
>Priority: Major
>
> {code}
> Running org.apache.drill.TestTpchDistributedConcurrent#testConcurrentQueries
> 16:38:21.784 [2505e212-b165-7812-5c91-0a407a213964:frag:3:1] ERROR 
> o.a.d.e.w.fragment.FragmentExecutor - SYSTEM ERROR: AssertionError
> Fragment 3:1
> [Error Id: 436120b6-5255-437e-af53-313e1c3207e0 on drillu1.qa.lab:31064]
> org.apache.drill.common.exceptions.UserException: SYSTEM ERROR: AssertionError
> Fragment 3:1
> [Error Id: 436120b6-5255-437e-af53-313e1c3207e0 on drillu1.qa.lab:31064]
>   at 
> org.apache.drill.common.exceptions.UserException$Builder.build(UserException.java:633)
>  ~[drill-common-1.14.0-SNAPSHOT.jar:1.14.0-SNAPSHOT]
>   at 
> org.apache.drill.exec.work.fragment.FragmentExecutor.sendFinalState(FragmentExecutor.java:359)
>  [classes/:na]
>   at 
> org.apache.drill.exec.work.fragment.FragmentExecutor.cleanup(FragmentExecutor.java:214)
>  [classes/:na]
>   at 
> org.apache.drill.exec.work.fragment.FragmentExecutor.run(FragmentExecutor.java:325)
>  [classes/:na]
>   at 
> org.apache.drill.common.SelfCleaningRunnable.run(SelfCleaningRunnable.java:38)
>  [drill-common-1.14.0-SNAPSHOT.jar:1.14.0-SNAPSHOT]
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>  [na:1.8.0_161]
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>  [na:1.8.0_161]
>   at java.lang.Thread.run(Thread.java:748) [na:1.8.0_161]
> Caused by: java.lang.RuntimeException: java.lang.AssertionError
>   at 
> org.apache.drill.common.DeferredException.addThrowable(DeferredException.java:101)
>  ~[drill-common-1.14.0-SNAPSHOT.jar:1.14.0-SNAPSHOT]
>   at 
> org.apache.drill.exec.work.fragment.FragmentExecutor.fail(FragmentExecutor.java:471)
>  [classes/:na]
>   at 
> org.apache.drill.exec.work.fragment.FragmentExecutor.run(FragmentExecutor.java:313)
>  [classes/:na]
>   ... 4 common frames omitted
> Caused by: java.lang.AssertionError: null
>   at 
> org.apache.drill.exec.compile.sig.MappingSet.enterConstant(MappingSet.java:85)
>  ~[classes/:na]
>   at 
> org.apache.drill.exec.expr.EvaluationVisitor$ConstantFilter.visitBooleanConstant(EvaluationVisitor.java:1376)
>  ~[classes/:na]
>   at 
> org.apache.drill.exec.expr.EvaluationVisitor$CSEFilter.visitBooleanConstant(EvaluationVisitor.java:1043)
>  ~[classes/:na]
>   at 
> org.apache.drill.exec.expr.EvaluationVisitor$CSEFilter.visitBooleanConstant(EvaluationVisitor.java:843)
>  ~[classes/:na]
>   at 
> org.apache.drill.common.expression.ValueExpressions$BooleanExpression.accept(ValueExpressions.java:186)
>  ~[drill-logical-1.14.0-SNAPSHOT.jar:1.14.0-SNAPSHOT]
>   at 
> org.apache.drill.exec.expr.EvaluationVisitor$EvalVisitor.visitReturnValueExpression(EvaluationVisitor.java:579)
>  ~[classes/:na]
>   at 
> org.apache.drill.exec.expr.EvaluationVisitor$EvalVisitor.visitUnknown(EvaluationVisitor.java:342)
>  ~[classes/:na]
>   at 
> org.apache.drill.exec.expr.EvaluationVisitor$ConstantFilter.visitUnknown(EvaluationVisitor.java:1399)
>  ~[classes/:na]
>   at 
> org.apache.drill.exec.expr.EvaluationVisitor$CSEFilter.visitUnknown(EvaluationVisitor.java:1084)
>  ~[classes/:na]
>   at 
> org.apache.drill.exec.expr.EvaluationVisitor$CSEFilter.visitUnknown(EvaluationVisitor.java:843)
>  ~[classes/:na]
>   at 
> org.apache.drill.exec.physical.impl.filter.ReturnValueExpression.accept(ReturnValueExpression.java:56)
>  ~[classes/:na]
>   at 
> org.apache.drill.exec.expr.EvaluationVisitor.addExpr(EvaluationVisitor.java:100)
>  ~[classes/:na]
>   at 
> org.apache.drill.exec.expr.ClassGenerator.addExpr(ClassGenerator.java:334) 
> ~[classes/:na]
>   at 
> org.apache.drill.exec.physical.impl.join.NestedLoopJoinBatch.setupWorker(NestedLoopJoinBatch.java:266)
>  ~[classes/:na]
>   at 
> org.apache.drill.exec.physical.impl.join.NestedLoopJoinBatch.buildSchema(NestedLoopJoinBatch.java:384)
>  ~[classes/:na]
>   at 
> org.apache.drill.exec.record.AbstractRecordBatch.next(AbstractRecordBatch.java:144)
>  ~[clas

[jira] [Updated] (DRILL-3964) CTAS fails with NPE when source JSON file is empty

[Vitalii Diravka (JIRA)]

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

Vitalii Diravka updated DRILL-3964:
---
Component/s: (was: Storage - Parquet)
 Storage - Writer

> CTAS fails with NPE when source JSON file is empty
> --
>
> Key: DRILL-3964
> URL: https://issues.apache.org/jira/browse/DRILL-3964
> Project: Apache Drill
>  Issue Type: Bug
>  Components: Storage - Writer
>Affects Versions: 1.2.0
>Reporter: Abhishek Girish
>Assignee: Gautam Kumar Parai
>Priority: Major
>  Labels: ready-to-commit
> Fix For: 1.14.0
>
>
> {code:sql}
> CREATE TABLE `complex.json` AS
>   SELECT id,
>  gbyi,
>  gbyt,
>  fl,
>  nul,
>  bool,
>  str,
>  sia,
>  sfa,
>  soa,
>  ooa,
>  oooi,
>  ooof,
>  ooos,
>  oooa
> FROM   dfs.`/drill/testdata/complex/json/complex.json`;
> Error: SYSTEM ERROR: NullPointerException
> Fragment 0:0
> [Error Id: 97679667-412a-475f-aebf-e935405c7330 on drill-democ1:31010] 
> (state=,code=0)
> {code}
> {code:sql}
> > select * from dfs.`/drill/testdata/complex/json/complex.json` limit 1;
> +--+
> |  |
> +--+
> +--+
> No rows selected (0.295 seconds)
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (DRILL-3964) CTAS fails with NPE when source JSON file is empty

[Vitalii Diravka (JIRA)]

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

Vitalii Diravka updated DRILL-3964:
---
Fix Version/s: 1.14.0

> CTAS fails with NPE when source JSON file is empty
> --
>
> Key: DRILL-3964
> URL: https://issues.apache.org/jira/browse/DRILL-3964
> Project: Apache Drill
>  Issue Type: Bug
>  Components: Storage - Parquet
>Affects Versions: 1.2.0
>Reporter: Abhishek Girish
>Assignee: Gautam Kumar Parai
>Priority: Major
>  Labels: ready-to-commit
> Fix For: 1.14.0
>
>
> {code:sql}
> CREATE TABLE `complex.json` AS
>   SELECT id,
>  gbyi,
>  gbyt,
>  fl,
>  nul,
>  bool,
>  str,
>  sia,
>  sfa,
>  soa,
>  ooa,
>  oooi,
>  ooof,
>  ooos,
>  oooa
> FROM   dfs.`/drill/testdata/complex/json/complex.json`;
> Error: SYSTEM ERROR: NullPointerException
> Fragment 0:0
> [Error Id: 97679667-412a-475f-aebf-e935405c7330 on drill-democ1:31010] 
> (state=,code=0)
> {code}
> {code:sql}
> > select * from dfs.`/drill/testdata/complex/json/complex.json` limit 1;
> +--+
> |  |
> +--+
> +--+
> No rows selected (0.295 seconds)
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (DRILL-3539) CTAS over empty json file throws NPE

[Vitalii Diravka (JIRA)]

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

Vitalii Diravka updated DRILL-3539:
---
Fix Version/s: (was: Future)
   1.14.0

> CTAS over empty json file throws NPE
> 
>
> Key: DRILL-3539
> URL: https://issues.apache.org/jira/browse/DRILL-3539
> Project: Apache Drill
>  Issue Type: Bug
>  Components: Execution - Flow
>Affects Versions: 1.2.0
>Reporter: Khurram Faraaz
>Assignee: Gautam Kumar Parai
>Priority: Major
> Fix For: 1.14.0
>
>
> CTAS over empty JSON file results in NPE.
> {code}
> 0: jdbc:drill:schema=dfs.tmp> create table t45645 as select * from 
> `empty.json`;
> Error: SYSTEM ERROR: NullPointerException
> Fragment 0:0
> [Error Id: 79039288-5402-4b0a-b32d-5bf5024f3b71 on centos-02.qa.lab:31010] 
> (state=,code=0)
> {code}
> Stack trace from drillbit.log
> {code}
> 2015-07-22 00:34:03,788 [2a511b03-90b3-1d39-f4e3-cfd754aa085f:frag:0:0] ERROR 
> o.a.d.e.w.fragment.FragmentExecutor - SYSTEM ERROR: NullPointerException
> Fragment 0:0
> [Error Id: 79039288-5402-4b0a-b32d-5bf5024f3b71 on centos-02.qa.lab:31010]
> org.apache.drill.common.exceptions.UserException: SYSTEM ERROR: 
> NullPointerException
> Fragment 0:0
> [Error Id: 79039288-5402-4b0a-b32d-5bf5024f3b71 on centos-02.qa.lab:31010]
> at 
> org.apache.drill.common.exceptions.UserException$Builder.build(UserException.java:523)
>  ~[drill-common-1.2.0-SNAPSHOT.jar:1.2.0-SNAPSHOT]
> at 
> org.apache.drill.exec.work.fragment.FragmentExecutor.sendFinalState(FragmentExecutor.java:323)
>  [drill-java-exec-1.2.0-SNAPSHOT.jar:1.2.0-SNAPSHOT]
> at 
> org.apache.drill.exec.work.fragment.FragmentExecutor.cleanup(FragmentExecutor.java:178)
>  [drill-java-exec-1.2.0-SNAPSHOT.jar:1.2.0-SNAPSHOT]
> at 
> org.apache.drill.exec.work.fragment.FragmentExecutor.run(FragmentExecutor.java:292)
>  [drill-java-exec-1.2.0-SNAPSHOT.jar:1.2.0-SNAPSHOT]
> at 
> org.apache.drill.common.SelfCleaningRunnable.run(SelfCleaningRunnable.java:38)
>  [drill-common-1.2.0-SNAPSHOT.jar:1.2.0-SNAPSHOT]
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>  [na:1.7.0_45]
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>  [na:1.7.0_45]
> at java.lang.Thread.run(Thread.java:744) [na:1.7.0_45]
> Caused by: java.lang.NullPointerException: null
> at 
> org.apache.drill.exec.physical.impl.WriterRecordBatch.addOutputContainerData(WriterRecordBatch.java:133)
>  ~[drill-java-exec-1.2.0-SNAPSHOT.jar:1.2.0-SNAPSHOT]
> at 
> org.apache.drill.exec.physical.impl.WriterRecordBatch.innerNext(WriterRecordBatch.java:126)
>  ~[drill-java-exec-1.2.0-SNAPSHOT.jar:1.2.0-SNAPSHOT]
> at 
> org.apache.drill.exec.record.AbstractRecordBatch.next(AbstractRecordBatch.java:147)
>  ~[drill-java-exec-1.2.0-SNAPSHOT.jar:1.2.0-SNAPSHOT]
> at 
> org.apache.drill.exec.record.AbstractRecordBatch.next(AbstractRecordBatch.java:105)
>  ~[drill-java-exec-1.2.0-SNAPSHOT.jar:1.2.0-SNAPSHOT]
> at 
> org.apache.drill.exec.record.AbstractRecordBatch.next(AbstractRecordBatch.java:95)
>  ~[drill-java-exec-1.2.0-SNAPSHOT.jar:1.2.0-SNAPSHOT]
> at 
> org.apache.drill.exec.record.AbstractSingleRecordBatch.innerNext(AbstractSingleRecordBatch.java:51)
>  ~[drill-java-exec-1.2.0-SNAPSHOT.jar:1.2.0-SNAPSHOT]
> at 
> org.apache.drill.exec.physical.impl.project.ProjectRecordBatch.innerNext(ProjectRecordBatch.java:129)
>  ~[drill-java-exec-1.2.0-SNAPSHOT.jar:1.2.0-SNAPSHOT]
> at 
> org.apache.drill.exec.record.AbstractRecordBatch.next(AbstractRecordBatch.java:147)
>  ~[drill-java-exec-1.2.0-SNAPSHOT.jar:1.2.0-SNAPSHOT]
> at 
> org.apache.drill.exec.physical.impl.BaseRootExec.next(BaseRootExec.java:83) 
> ~[drill-java-exec-1.2.0-SNAPSHOT.jar:1.2.0-SNAPSHOT]
> at 
> org.apache.drill.exec.physical.impl.ScreenCreator$ScreenRoot.innerNext(ScreenCreator.java:79)
>  ~[drill-java-exec-1.2.0-SNAPSHOT.jar:1.2.0-SNAPSHOT]
> at 
> org.apache.drill.exec.physical.impl.BaseRootExec.next(BaseRootExec.java:73) 
> ~[drill-java-exec-1.2.0-SNAPSHOT.jar:1.2.0-SNAPSHOT]
> at 
> org.apache.drill.exec.work.fragment.FragmentExecutor$1.run(FragmentExecutor.java:258)
>  ~[drill-java-exec-1.2.0-SNAPSHOT.jar:1.2.0-SNAPSHOT]
> at 
> org.apache.drill.exec.work.fragment.FragmentExecutor$1.run(FragmentExecutor.java:252)
>  ~[drill-java-exec-1.2.0-SNAPSHOT.jar:1.2.0-SNAPSHOT]
> at java.security.AccessController.doPrivileged(Native Method) 
> ~[na:1.7.0_45]
> at javax.security.auth.Subject.doAs(Subject.java:415) ~[na:1.7.0_45]
> at 
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1566)
>  ~[hadoop-commo