[jira] [Updated] (DRILL-4897) NumberFormatException in Drill SQL while casting to BIGINT when its actually a number

[Pritesh Maker (JIRA)]

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

Pritesh Maker updated DRILL-4897:
-
Fix Version/s: 1.14.0

> NumberFormatException in Drill SQL while casting to BIGINT when its actually 
> a number
> -
>
> Key: DRILL-4897
> URL: https://issues.apache.org/jira/browse/DRILL-4897
> Project: Apache Drill
>  Issue Type: Bug
>  Components: Functions - Drill
>Reporter: Srihari Karanth
>Assignee: Karthikeyan Manivannan
>Priority: Blocker
> Fix For: 1.14.0
>
>
> In the following SQL, drill cribs when trying to convert a number which is in 
> varchar
>select cast (case IsNumeric(Delta_Radio_Delay)  
> when 0 then 0 else Delta_Radio_Delay end as BIGINT) 
> from datasource.`./sometable` 
> where Delta_Radio_Delay='4294967294';
> BIGINT should be able to take very large number. I dont understand how it 
> throws the below error:
> 0: jdbc:drill:> select cast (case IsNumeric(Delta_Radio_Delay)  
> when 0 then 0 else Delta_Radio_Delay end as BIGINT) 
> from datasource.`./sometable` 
> where Delta_Radio_Delay='4294967294';
> Error: SYSTEM ERROR: NumberFormatException: 4294967294
> Fragment 1:29
> [Error Id: a63bb113-271f-4d8b-8194-2c9728543200 on cluster-3:31010] 
> (state=,code=0)
> How can i modify SQL to fix this?



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

[jira] [Assigned] (DRILL-6273) Remove dependency licensed under Category X

[Pritesh Maker (JIRA)]

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

Pritesh Maker reassigned DRILL-6273:


Assignee: Venkata Jyothsna Donapati

> Remove dependency licensed under Category X
> ---
>
> Key: DRILL-6273
> URL: https://issues.apache.org/jira/browse/DRILL-6273
> Project: Apache Drill
>  Issue Type: Task
>Reporter: Vlad Rozov
>Assignee: Venkata Jyothsna Donapati
>Priority: Critical
> Fix For: 1.14.0
>
>




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

[jira] [Updated] (DRILL-6282) Excluding io.dropwizard.metrics dependencies

[Vitalii Diravka (JIRA)]

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

Vitalii Diravka updated DRILL-6282:
---
Reviewer: Vlad Rozov

> Excluding io.dropwizard.metrics dependencies
> 
>
> Key: DRILL-6282
> URL: https://issues.apache.org/jira/browse/DRILL-6282
> Project: Apache Drill
>  Issue Type: Bug
>  Components: Tools, Build  Test
>Affects Versions: 1.13.0
>Reporter: Vitalii Diravka
>Assignee: Vitalii Diravka
>Priority: Major
> Fix For: 1.14.0
>
>
> There are three types of metrics-core in Drill: 
> 1. _com.yammer.metrics_, 
> 2. _com.codahale.metrics_, 
> 3. _io.dropwizard.metrics_
> Drill uses only 1 and 2. The last 3 one is used by Hive.
> 1st one has different class full identifiers, but the 2 and 3 ones have the 
> same class full identifiers and maven doesn't know which library to use 
> ([https://github.com/dropwizard/metrics/issues/1044]).
> But I found that 3 one library is used by Hive only for tests, therefore it 
> is not required for Drill and could be excluded from hive-metastore and 
> hive-exec.
> The dependencies conflict is related not only to metrics-core, but to 
> metrics-servlets and metrics-json as well.
> All these metrics should be organized with proper excluding and dependency 
> management blocks.



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

[jira] [Commented] (DRILL-6282) Excluding io.dropwizard.metrics dependencies

[ASF GitHub Bot (JIRA)]

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

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

Github user vdiravka commented on the issue:

https://github.com/apache/drill/pull/1189
  
@vrozov Could you please review this, since you were the reviewer for 
DRILL-5978 (Hive upgrade)


> Excluding io.dropwizard.metrics dependencies
> 
>
> Key: DRILL-6282
> URL: https://issues.apache.org/jira/browse/DRILL-6282
> Project: Apache Drill
>  Issue Type: Bug
>  Components: Tools, Build  Test
>Affects Versions: 1.13.0
>Reporter: Vitalii Diravka
>Assignee: Vitalii Diravka
>Priority: Major
> Fix For: 1.14.0
>
>
> There are three types of metrics-core in Drill: 
> 1. _com.yammer.metrics_, 
> 2. _com.codahale.metrics_, 
> 3. _io.dropwizard.metrics_
> Drill uses only 1 and 2. The last 3 one is used by Hive.
> 1st one has different class full identifiers, but the 2 and 3 ones have the 
> same class full identifiers and maven doesn't know which library to use 
> ([https://github.com/dropwizard/metrics/issues/1044]).
> But I found that 3 one library is used by Hive only for tests, therefore it 
> is not required for Drill and could be excluded from hive-metastore and 
> hive-exec.
> The dependencies conflict is related not only to metrics-core, but to 
> metrics-servlets and metrics-json as well.
> All these metrics should be organized with proper excluding and dependency 
> management blocks.



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

[jira] [Commented] (DRILL-6282) Excluding io.dropwizard.metrics dependencies

[ASF GitHub Bot (JIRA)]

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

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

GitHub user vdiravka opened a pull request:

https://github.com/apache/drill/pull/1189

DRILL-6282: Excluding io.dropwizard.metrics dependencies



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/vdiravka/drill DRILL-6282

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/drill/pull/1189.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1189


commit d0c6a5d6598ef384c1bca7f34db7923809f31980
Author: Vitalii Diravka 
Date:   2018-03-21T14:16:10Z

DRILL-6282: Excluding io.dropwizard.metrics dependencies




> Excluding io.dropwizard.metrics dependencies
> 
>
> Key: DRILL-6282
> URL: https://issues.apache.org/jira/browse/DRILL-6282
> Project: Apache Drill
>  Issue Type: Bug
>  Components: Tools, Build  Test
>Affects Versions: 1.13.0
>Reporter: Vitalii Diravka
>Assignee: Vitalii Diravka
>Priority: Major
> Fix For: 1.14.0
>
>
> There are three types of metrics-core in Drill: 
> 1. _com.yammer.metrics_, 
> 2. _com.codahale.metrics_, 
> 3. _io.dropwizard.metrics_
> Drill uses only 1 and 2. The last 3 one is used by Hive.
> 1st one has different class full identifiers, but the 2 and 3 ones have the 
> same class full identifiers and maven doesn't know which library to use 
> ([https://github.com/dropwizard/metrics/issues/1044]).
> But I found that 3 one library is used by Hive only for tests, therefore it 
> is not required for Drill and could be excluded from hive-metastore and 
> hive-exec.
> The dependencies conflict is related not only to metrics-core, but to 
> metrics-servlets and metrics-json as well.
> All these metrics should be organized with proper excluding and dependency 
> management blocks.



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

[jira] [Updated] (DRILL-6288) Upgrade org.javassist:javassist and org.reflections:reflections

[Vitalii Diravka (JIRA)]

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

Vitalii Diravka updated DRILL-6288:
---
Labels: ready-to-commit  (was: )

> Upgrade org.javassist:javassist and org.reflections:reflections
> ---
>
> Key: DRILL-6288
> URL: https://issues.apache.org/jira/browse/DRILL-6288
> Project: Apache Drill
>  Issue Type: Task
>Reporter: Vlad Rozov
>Assignee: Vlad Rozov
>Priority: Major
>  Labels: ready-to-commit
> Fix For: 1.14.0
>
>
> Current {{org.javassist:javassist}} version {{3.16.1-GA}} does not support 
> JDK 1.8. Need to upgrade to {{3.18.2-GA}} or above. See [Reflections - Java 8 
> - invalid constant 
> type|https://stackoverflow.com/questions/30313255/reflections-java-8-invalid-constant-type]



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

[jira] [Commented] (DRILL-6288) Upgrade org.javassist:javassist and org.reflections:reflections

[ASF GitHub Bot (JIRA)]

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

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

Github user vdiravka commented on a diff in the pull request:

https://github.com/apache/drill/pull/1185#discussion_r176891810
  
--- Diff: exec/jdbc-all/pom.xml ---
@@ -559,7 +559,7 @@
   This is likely due to you adding new 
dependencies to a java-exec and not updating the excludes in this module. This 
is important as it minimizes the size of the dependency of Drill application 
users.
 
 
-3200
+3300
--- End diff --

This has increased due to the new size of javassist library?


> Upgrade org.javassist:javassist and org.reflections:reflections
> ---
>
> Key: DRILL-6288
> URL: https://issues.apache.org/jira/browse/DRILL-6288
> Project: Apache Drill
>  Issue Type: Task
>Reporter: Vlad Rozov
>Assignee: Vlad Rozov
>Priority: Major
> Fix For: 1.14.0
>
>
> Current {{org.javassist:javassist}} version {{3.16.1-GA}} does not support 
> JDK 1.8. Need to upgrade to {{3.18.2-GA}} or above. See [Reflections - Java 8 
> - invalid constant 
> type|https://stackoverflow.com/questions/30313255/reflections-java-8-invalid-constant-type]



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

[jira] [Commented] (DRILL-6271) Update copyright range in NOTICE

[ASF GitHub Bot (JIRA)]

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

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

GitHub user dvjyothsna opened a pull request:

https://github.com/apache/drill/pull/1188

DRILL-6271: Updated copyright range in NOTICE

@vrozov please review 

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/dvjyothsna/drill DRILL-6271

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/drill/pull/1188.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1188






> Update copyright range in NOTICE
> 
>
> Key: DRILL-6271
> URL: https://issues.apache.org/jira/browse/DRILL-6271
> Project: Apache Drill
>  Issue Type: Task
>Reporter: Vlad Rozov
>Assignee: Venkata Jyothsna Donapati
>Priority: Major
> Fix For: 1.14.0
>
>




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

[jira] [Commented] (DRILL-6286) Regression: incorrect reference to shutdown in drillbit.log

[ASF GitHub Bot (JIRA)]

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

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

Github user dvjyothsna closed the pull request at:

https://github.com/apache/drill/pull/1187


> Regression: incorrect reference to shutdown in drillbit.log
> ---
>
> Key: DRILL-6286
> URL: https://issues.apache.org/jira/browse/DRILL-6286
> Project: Apache Drill
>  Issue Type: Bug
>Reporter: Vlad Rozov
>Assignee: Venkata Jyothsna Donapati
>Priority: Major
> Fix For: 1.14.0
>
>
> drillbit.log refers to shutdown even in cases when no shutdown sequence was 
> initiated:
> {noformat}
> 2018-03-16 11:55:52,693 [drill-executor-19] INFO  
> o.apache.drill.exec.work.WorkManager - Waiting for 0 queries to complete 
> before shutting down
> 2018-03-16 11:55:52,693 [drill-executor-19] INFO  
> o.apache.drill.exec.work.WorkManager - Waiting for 3 running fragments to 
> complete before shutting down
> {noformat}



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

[jira] [Commented] (DRILL-6286) Regression: incorrect reference to shutdown in drillbit.log

[ASF GitHub Bot (JIRA)]

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

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

Github user dvjyothsna commented on the issue:

https://github.com/apache/drill/pull/1187
  
@vrozov Please review 


> Regression: incorrect reference to shutdown in drillbit.log
> ---
>
> Key: DRILL-6286
> URL: https://issues.apache.org/jira/browse/DRILL-6286
> Project: Apache Drill
>  Issue Type: Bug
>Reporter: Vlad Rozov
>Assignee: Venkata Jyothsna Donapati
>Priority: Major
> Fix For: 1.14.0
>
>
> drillbit.log refers to shutdown even in cases when no shutdown sequence was 
> initiated:
> {noformat}
> 2018-03-16 11:55:52,693 [drill-executor-19] INFO  
> o.apache.drill.exec.work.WorkManager - Waiting for 0 queries to complete 
> before shutting down
> 2018-03-16 11:55:52,693 [drill-executor-19] INFO  
> o.apache.drill.exec.work.WorkManager - Waiting for 3 running fragments to 
> complete before shutting down
> {noformat}



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

[jira] [Commented] (DRILL-6286) Regression: incorrect reference to shutdown in drillbit.log

[ASF GitHub Bot (JIRA)]

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

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

GitHub user dvjyothsna opened a pull request:

https://github.com/apache/drill/pull/1187

DRILL-6286: Updated copyright range in NOTICE



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/dvjyothsna/drill DRILL-6286

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/drill/pull/1187.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1187


commit 935a0ad6e8c130437e2b55aa91e84e57e1f1
Author: dvjyothsna 
Date:   2018-03-24T00:06:50Z

DRILL-6286: Updated copyright range in NOTICE




> Regression: incorrect reference to shutdown in drillbit.log
> ---
>
> Key: DRILL-6286
> URL: https://issues.apache.org/jira/browse/DRILL-6286
> Project: Apache Drill
>  Issue Type: Bug
>Reporter: Vlad Rozov
>Assignee: Venkata Jyothsna Donapati
>Priority: Major
> Fix For: 1.14.0
>
>
> drillbit.log refers to shutdown even in cases when no shutdown sequence was 
> initiated:
> {noformat}
> 2018-03-16 11:55:52,693 [drill-executor-19] INFO  
> o.apache.drill.exec.work.WorkManager - Waiting for 0 queries to complete 
> before shutting down
> 2018-03-16 11:55:52,693 [drill-executor-19] INFO  
> o.apache.drill.exec.work.WorkManager - Waiting for 3 running fragments to 
> complete before shutting down
> {noformat}



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

[jira] [Created] (DRILL-6292) Improve error message when NTLM token is sent to server using SPNEGO

[Krystal (JIRA)]

Krystal created DRILL-6292:
--

 Summary: Improve error message when NTLM token is sent to server 
using SPNEGO
 Key: DRILL-6292
 URL: https://issues.apache.org/jira/browse/DRILL-6292
 Project: Apache Drill
  Issue Type: Improvement
  Components: Client - Java
Reporter: Krystal


The following error message is logged in drillbit.log file when the brower 
sends NTLM token instead of SPNEGO token.

{color:#00}WARN o.a.d.e.s.r.a.DrillSpnegoLoginService - Caught GSSException 
trying to authenticate the client org.ietf.jgss.GSSException: Defective token 
detected (Mechanism level: GSSHeader did not find the right tag){color}

Should have a clearer error that indicates the token sent is of NTLM.



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

[jira] [Updated] (DRILL-6290) Refactor TestInfoSchemaFilterPushDown tests to use PlanTestBase utility methods

[Vitalii Diravka (JIRA)]

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

Vitalii Diravka updated DRILL-6290:
---
Labels: ready-to-commit  (was: )

> Refactor TestInfoSchemaFilterPushDown tests to use PlanTestBase utility 
> methods
> ---
>
> Key: DRILL-6290
> URL: https://issues.apache.org/jira/browse/DRILL-6290
> Project: Apache Drill
>  Issue Type: Task
>Reporter: Arina Ielchiieva
>Assignee: Arina Ielchiieva
>Priority: Minor
>  Labels: ready-to-commit
> Fix For: 1.14.0
>
>
> PlanTestBase has useful utility methods to match query plans.
> It would be useful to TestInfoSchemaFilterPushDown to use such utility 
> methods plus loosen expected pattern to match exactly what is needed rather 
> then the whole string.



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

[jira] [Commented] (DRILL-6290) Refactor TestInfoSchemaFilterPushDown tests to use PlanTestBase utility methods

[ASF GitHub Bot (JIRA)]

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

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

Github user vdiravka commented on the issue:

https://github.com/apache/drill/pull/1186
  
+1
Thank you for improving the old code


> Refactor TestInfoSchemaFilterPushDown tests to use PlanTestBase utility 
> methods
> ---
>
> Key: DRILL-6290
> URL: https://issues.apache.org/jira/browse/DRILL-6290
> Project: Apache Drill
>  Issue Type: Task
>Reporter: Arina Ielchiieva
>Assignee: Arina Ielchiieva
>Priority: Minor
> Fix For: 1.14.0
>
>
> PlanTestBase has useful utility methods to match query plans.
> It would be useful to TestInfoSchemaFilterPushDown to use such utility 
> methods plus loosen expected pattern to match exactly what is needed rather 
> then the whole string.



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

[jira] [Resolved] (DRILL-6261) logging "Waiting for X queries to complete before shutting down" even before shutdown request is triggered

[Pritesh Maker (JIRA)]

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

Pritesh Maker resolved DRILL-6261.
--
Resolution: Duplicate

Duplicate of DRILL-6286

> logging "Waiting for X queries to complete before shutting down" even before 
> shutdown request is triggered
> --
>
> Key: DRILL-6261
> URL: https://issues.apache.org/jira/browse/DRILL-6261
> Project: Apache Drill
>  Issue Type: Bug
>Reporter: Venkata Jyothsna Donapati
>Assignee: Venkata Jyothsna Donapati
>Priority: Major
>
> After https://issues.apache.org/jira/browse/DRILL-5922 changes "Waiting for X 
> queries to complete before shutting down" is logged every time a query runs 
> instead of it being logged after a shutdown request is triggered.



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

[jira] [Assigned] (DRILL-6261) logging "Waiting for X queries to complete before shutting down" even before shutdown request is triggered

[Pritesh Maker (JIRA)]

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

Pritesh Maker reassigned DRILL-6261:


Assignee: Venkata Jyothsna Donapati

> logging "Waiting for X queries to complete before shutting down" even before 
> shutdown request is triggered
> --
>
> Key: DRILL-6261
> URL: https://issues.apache.org/jira/browse/DRILL-6261
> Project: Apache Drill
>  Issue Type: Bug
>Reporter: Venkata Jyothsna Donapati
>Assignee: Venkata Jyothsna Donapati
>Priority: Major
>
> After https://issues.apache.org/jira/browse/DRILL-5922 changes "Waiting for X 
> queries to complete before shutting down" is logged every time a query runs 
> instead of it being logged after a shutdown request is triggered.



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

[jira] [Commented] (DRILL-6224) The metrics' page has gauges reset to near zero values and does not seem to update

[ASF GitHub Bot (JIRA)]

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

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

Github user arina-ielchiieva commented on the issue:

https://github.com/apache/drill/pull/1160
  
+1, thanks for making the changes.


> The metrics' page has gauges reset to near zero values and does not seem to 
> update
> --
>
> Key: DRILL-6224
> URL: https://issues.apache.org/jira/browse/DRILL-6224
> Project: Apache Drill
>  Issue Type: Bug
>  Components: Web Server
>Affects Versions: 1.12.0
>Reporter: Kunal Khatua
>Assignee: Kunal Khatua
>Priority: Major
>  Labels: ready-to-commit
> Fix For: 1.14.0
>
>
> When viewing http://:8047/metrics#gauges
> The gauges reset to near zero values and does not seem to update.
> Tracing the server calls made, I see the following:
> {code:json}
> {version: "3.0.0", gauges: {G1-Old-Generation.count: {value: 0}, 
> G1-Old-Generation.time: {value: 0},…},…}
> counters :
>   {drill.connections.rpc.control.encrypted: {count: 0},…}
> gauges :
>   {G1-Old-Generation.count: {value: 0}, G1-Old-Generation.time: {value: 0},…}
> histograms :   {,…}
> meters : {}
> timers : {}
> version : "3.0.0"
> {code}
> This looks incorrect and would explain why the metrics appear to be 
> incomplete.



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

[jira] [Commented] (DRILL-6242) Output format for nested date, time, timestamp values in an object hierarchy

[Jiang Wu (JIRA)]

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

Jiang Wu commented on DRILL-6242:
-

Hmm.  The testing is failing due to the TimeZone aspect of date time handling.  
Looking at the code, when the data is read out from a Drill vector, the code 
does:
{code:java}
<#if minor.class == "Date">
    @Override
    public ${friendlyType} getObject(int index) {
      org.joda.time.DateTime date = new org.joda.time.DateTime(get(index), 
org.joda.time.DateTimeZone.UTC);
      date = date.withZoneRetainFields(org.joda.time.DateTimeZone.getDefault());
      return new java.sql.Date(date.getMillis());
    }
{code}
The code "withZoneRetainFields()" actually modifies the time value 
in milliseconds.  While this produces a textual representation that looks the 
same as the "UTC" textual representation, wouldn't this cause CTAS to output a 
different real value?

 

> Output format for nested date, time, timestamp values in an object hierarchy
> 
>
> Key: DRILL-6242
> URL: https://issues.apache.org/jira/browse/DRILL-6242
> Project: Apache Drill
>  Issue Type: Bug
>  Components: Execution - Data Types
>Affects Versions: 1.12.0
>Reporter: Jiang Wu
>Priority: Major
>
> Some storages (mapr db, mongo db, etc.) have hierarchical objects that 
> contain nested fields of date, time, timestamp types.  When a query returns 
> these objects, the output format for the nested date, time, timestamp, are 
> showing the internal object (org.joda.time.DateTime), rather than the logical 
> data value.
> For example.  Suppose in MongoDB, we have a single object that looks like 
> this:
> {code:java}
> > db.test.findOne();
> {
> "_id" : ObjectId("5aa8487d470dd39a635a12f5"),
> "name" : "orange",
> "context" : {
> "date" : ISODate("2018-03-13T21:52:54.940Z"),
> "user" : "jack"
> }
> }
> {code}
> Then connect Drill to the above MongoDB storage, and run the following query 
> within Drill:
> {code:java}
> > select t.context.`date`, t.context from test t; 
> ++-+ 
> | EXPR$0 | context | 
> ++-+ 
> | 2018-03-13 | 
> {"date":{"dayOfYear":72,"year":2018,"dayOfMonth":13,"dayOfWeek":2,"era":1,"millisOfDay":78774940,"weekOfWeekyear":11,"weekyear":2018,"monthOfYear":3,"yearOfEra":2018,"yearOfCentury":18,"centuryOfEra":20,"millisOfSecond":940,"secondOfMinute":54,"secondOfDay":78774,"minuteOfHour":52,"minuteOfDay":1312,"hourOfDay":21,"zone":{"fixed":true,"id":"UTC"},"millis":1520977974940,"chronology":{"zone":{"fixed":true,"id":"UTC"}},"afterNow":false,"beforeNow":true,"equalNow":false},"user":"jack"}
>  |
> {code}
> We can see that from the above output, when the date field is retrieved as a 
> top level column, Drill outputs a logical date value.  But when the same 
> field is within an object hierarchy, Drill outputs the internal object used 
> to hold the date value.
> The expected output is the same display for whether the date field is shown 
> as a top level column or when it is within an object hierarchy:
> {code:java}
> > select t.context.`date`, t.context from test t; 
> ++-+ 
> | EXPR$0 | context | 
> ++-+ 
> | 2018-03-13 | {"date":"2018-03-13","user":"jack"} |
> {code}



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

[jira] [Commented] (DRILL-6224) The metrics' page has gauges reset to near zero values and does not seem to update

[ASF GitHub Bot (JIRA)]

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

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

Github user kkhatua commented on the issue:

https://github.com/apache/drill/pull/1160
  
During a freshly setup Drillbit:

![image](https://user-images.githubusercontent.com/4335237/37847547-644fa67c-2e8e-11e8-9aa7-2b4adf499cd0.png)

While running 2 large (600M rows) join query on a 4 node setup, and one 
completes:

![image](https://user-images.githubusercontent.com/4335237/37847633-b4dd5a76-2e8e-11e8-9c1d-87c3a0f9f3e7.png)

The Heap Usage percentage is based on {{heapUsed/heapMax}}
The Actively Used Direct percentage is based on 
{{currentDirectInUse/PeakDirectUsed}} 
This is because the actual total direct memory used by Netty is not 
exposed. However, this does tell how much the Drillbit is using at the moment.


> The metrics' page has gauges reset to near zero values and does not seem to 
> update
> --
>
> Key: DRILL-6224
> URL: https://issues.apache.org/jira/browse/DRILL-6224
> Project: Apache Drill
>  Issue Type: Bug
>  Components: Web Server
>Affects Versions: 1.12.0
>Reporter: Kunal Khatua
>Assignee: Kunal Khatua
>Priority: Major
>  Labels: ready-to-commit
> Fix For: 1.14.0
>
>
> When viewing http://:8047/metrics#gauges
> The gauges reset to near zero values and does not seem to update.
> Tracing the server calls made, I see the following:
> {code:json}
> {version: "3.0.0", gauges: {G1-Old-Generation.count: {value: 0}, 
> G1-Old-Generation.time: {value: 0},…},…}
> counters :
>   {drill.connections.rpc.control.encrypted: {count: 0},…}
> gauges :
>   {G1-Old-Generation.count: {value: 0}, G1-Old-Generation.time: {value: 0},…}
> histograms :   {,…}
> meters : {}
> timers : {}
> version : "3.0.0"
> {code}
> This looks incorrect and would explain why the metrics appear to be 
> incomplete.



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

[jira] [Assigned] (DRILL-6224) The metrics' page has gauges reset to near zero values and does not seem to update

[Arina Ielchiieva (JIRA)]

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

Arina Ielchiieva reassigned DRILL-6224:
---

Assignee: Kunal Khatua  (was: Arina Ielchiieva)

> The metrics' page has gauges reset to near zero values and does not seem to 
> update
> --
>
> Key: DRILL-6224
> URL: https://issues.apache.org/jira/browse/DRILL-6224
> Project: Apache Drill
>  Issue Type: Bug
>  Components: Web Server
>Affects Versions: 1.12.0
>Reporter: Kunal Khatua
>Assignee: Kunal Khatua
>Priority: Major
>  Labels: ready-to-commit
> Fix For: 1.14.0
>
>
> When viewing http://:8047/metrics#gauges
> The gauges reset to near zero values and does not seem to update.
> Tracing the server calls made, I see the following:
> {code:json}
> {version: "3.0.0", gauges: {G1-Old-Generation.count: {value: 0}, 
> G1-Old-Generation.time: {value: 0},…},…}
> counters :
>   {drill.connections.rpc.control.encrypted: {count: 0},…}
> gauges :
>   {G1-Old-Generation.count: {value: 0}, G1-Old-Generation.time: {value: 0},…}
> histograms :   {,…}
> meters : {}
> timers : {}
> version : "3.0.0"
> {code}
> This looks incorrect and would explain why the metrics appear to be 
> incomplete.



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

[jira] [Assigned] (DRILL-6224) The metrics' page has gauges reset to near zero values and does not seem to update

[Arina Ielchiieva (JIRA)]

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

Arina Ielchiieva reassigned DRILL-6224:
---

Assignee: Arina Ielchiieva  (was: Kunal Khatua)

> The metrics' page has gauges reset to near zero values and does not seem to 
> update
> --
>
> Key: DRILL-6224
> URL: https://issues.apache.org/jira/browse/DRILL-6224
> Project: Apache Drill
>  Issue Type: Bug
>  Components: Web Server
>Affects Versions: 1.12.0
>Reporter: Kunal Khatua
>Assignee: Arina Ielchiieva
>Priority: Major
>  Labels: ready-to-commit
> Fix For: 1.14.0
>
>
> When viewing http://:8047/metrics#gauges
> The gauges reset to near zero values and does not seem to update.
> Tracing the server calls made, I see the following:
> {code:json}
> {version: "3.0.0", gauges: {G1-Old-Generation.count: {value: 0}, 
> G1-Old-Generation.time: {value: 0},…},…}
> counters :
>   {drill.connections.rpc.control.encrypted: {count: 0},…}
> gauges :
>   {G1-Old-Generation.count: {value: 0}, G1-Old-Generation.time: {value: 0},…}
> histograms :   {,…}
> meters : {}
> timers : {}
> version : "3.0.0"
> {code}
> This looks incorrect and would explain why the metrics appear to be 
> incomplete.



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

[jira] [Commented] (DRILL-6224) The metrics' page has gauges reset to near zero values and does not seem to update

[ASF GitHub Bot (JIRA)]

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

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

Github user arina-ielchiieva commented on the issue:

https://github.com/apache/drill/pull/1160
  
+1


> The metrics' page has gauges reset to near zero values and does not seem to 
> update
> --
>
> Key: DRILL-6224
> URL: https://issues.apache.org/jira/browse/DRILL-6224
> Project: Apache Drill
>  Issue Type: Bug
>  Components: Web Server
>Affects Versions: 1.12.0
>Reporter: Kunal Khatua
>Assignee: Kunal Khatua
>Priority: Major
>  Labels: ready-to-commit
> Fix For: 1.14.0
>
>
> When viewing http://:8047/metrics#gauges
> The gauges reset to near zero values and does not seem to update.
> Tracing the server calls made, I see the following:
> {code:json}
> {version: "3.0.0", gauges: {G1-Old-Generation.count: {value: 0}, 
> G1-Old-Generation.time: {value: 0},…},…}
> counters :
>   {drill.connections.rpc.control.encrypted: {count: 0},…}
> gauges :
>   {G1-Old-Generation.count: {value: 0}, G1-Old-Generation.time: {value: 0},…}
> histograms :   {,…}
> meters : {}
> timers : {}
> version : "3.0.0"
> {code}
> This looks incorrect and would explain why the metrics appear to be 
> incomplete.



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

[jira] [Updated] (DRILL-6224) The metrics' page has gauges reset to near zero values and does not seem to update

[Arina Ielchiieva (JIRA)]

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

Arina Ielchiieva updated DRILL-6224:

Labels: ready-to-commit  (was: )

> The metrics' page has gauges reset to near zero values and does not seem to 
> update
> --
>
> Key: DRILL-6224
> URL: https://issues.apache.org/jira/browse/DRILL-6224
> Project: Apache Drill
>  Issue Type: Bug
>  Components: Web Server
>Affects Versions: 1.12.0
>Reporter: Kunal Khatua
>Assignee: Kunal Khatua
>Priority: Major
>  Labels: ready-to-commit
> Fix For: 1.14.0
>
>
> When viewing http://:8047/metrics#gauges
> The gauges reset to near zero values and does not seem to update.
> Tracing the server calls made, I see the following:
> {code:json}
> {version: "3.0.0", gauges: {G1-Old-Generation.count: {value: 0}, 
> G1-Old-Generation.time: {value: 0},…},…}
> counters :
>   {drill.connections.rpc.control.encrypted: {count: 0},…}
> gauges :
>   {G1-Old-Generation.count: {value: 0}, G1-Old-Generation.time: {value: 0},…}
> histograms :   {,…}
> meters : {}
> timers : {}
> version : "3.0.0"
> {code}
> This looks incorrect and would explain why the metrics appear to be 
> incomplete.



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

[jira] [Comment Edited] (DRILL-6247) Minor fragments remain in CANCELLATION_REQUESTED state after query failure

[Vlad Rozov (JIRA)]

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

Vlad Rozov edited comment on DRILL-6247 at 3/23/18 5:33 PM:


[~khfaraaz] Please take a stack trace after the query is canceled and enable 
DEBUG level logging.


was (Author: vrozov):
[~khfaraaz] Please take a stack trace after the query is canceled.

> Minor fragments remain in CANCELLATION_REQUESTED state after query failure
> --
>
> Key: DRILL-6247
> URL: https://issues.apache.org/jira/browse/DRILL-6247
> Project: Apache Drill
>  Issue Type: Bug
>  Components: Execution - Flow
>Affects Versions: 1.13.0
>Reporter: Khurram Faraaz
>Assignee: Vlad Rozov
>Priority: Major
> Attachments: 25569e98-10f9-2fe2-9dec-0a42f3ad45fa.sys.drill, 
> cancellation_requested_march_14.png, drillbit_snippet.log, 
> jstack_cancellation_requested.txt
>
>
> Once a query fails, in this case due to an OOM in RPC we see many minor 
> fragments are reported to be in CANCELLATION_REQUESTED state on Web UI after 
> query has failed. The problem is reproducible. drillbit.log for this failure 
> and jstack output are attached here.
> To reproduce the problem on a 4 node cluster.
> alter system reset all;
> alter system set `planner.slice_target`=1;
> Failing query => SELECT * , FLATTEN(arr) FROM many_json_files;
> Drill 1.13.0-SNAPSHOT, commit id: 766315ea17377199897d685ab801edd38394fe01
> Stack trace from output of jstack, fragment 0:0 is reported to be in 
> CANCELLATION_REQUESTED state on Drill Web UI
> jstack -l 13488 > jstack_DRILL_6235.txt
> {noformat}
> "25569e98-10f9-2fe2-9dec-0a42f3ad45fa:frag:0:0" #87 daemon prio=10 os_prio=0 
> tid=0x7f9d01374360 nid=0x2ff5 waiting on condition [0x7f9cd5536000]
>  java.lang.Thread.State: WAITING (parking)
>  at sun.misc.Unsafe.park(Native Method)
>  - parking to wait for <0x0007a388b300> (a 
> org.apache.drill.exec.rpc.ResettableBarrier$InternalSynchronizer)
>  at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>  at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
>  at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997)
>  at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304)
>  at 
> org.apache.drill.exec.rpc.ResettableBarrier.await(ResettableBarrier.java:70)
>  at 
> org.apache.drill.exec.rpc.AbstractRemoteConnection$WriteManager.waitForWritable(AbstractRemoteConnection.java:114)
>  at 
> org.apache.drill.exec.rpc.AbstractRemoteConnection.blockOnNotWritable(AbstractRemoteConnection.java:76)
>  at org.apache.drill.exec.rpc.RpcBus.send(RpcBus.java:108)
>  at 
> org.apache.drill.exec.rpc.user.UserServer$BitToUserConnection.sendData(UserServer.java:275)
>  at 
> org.apache.drill.exec.ops.AccountingUserConnection.sendData(AccountingUserConnection.java:42)
>  at 
> org.apache.drill.exec.physical.impl.ScreenCreator$ScreenRoot.innerNext(ScreenCreator.java:120)
>  at 
> org.apache.drill.exec.physical.impl.BaseRootExec.next(BaseRootExec.java:95)
>  at 
> org.apache.drill.exec.work.fragment.FragmentExecutor$1.run(FragmentExecutor.java:233)
>  at 
> org.apache.drill.exec.work.fragment.FragmentExecutor$1.run(FragmentExecutor.java:226)
>  at java.security.AccessController.doPrivileged(Native Method)
>  at javax.security.auth.Subject.doAs(Subject.java:422)
>  at 
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1595)
>  at 
> org.apache.drill.exec.work.fragment.FragmentExecutor.run(FragmentExecutor.java:226)
>  at 
> org.apache.drill.common.SelfCleaningRunnable.run(SelfCleaningRunnable.java:38)
>  at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>  at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>  at java.lang.Thread.run(Thread.java:748)
> {noformat}
> Stack trace from drillbit.log
> {noformat}
> 2018-03-14 10:52:44,545 [25569e98-10f9-2fe2-9dec-0a42f3ad45fa:frag:1:49] INFO 
> o.a.d.e.w.fragment.FragmentExecutor - User Error Occurred: One or more nodes 
> ran out of memory while executing the query. (Failure allocating buffer.)
> org.apache.drill.common.exceptions.UserException: RESOURCE ERROR: One or more 
> nodes ran out of memory while executing the query.
> Failure allocating buffer.
> [Error Id: b83884df-af31-411a-9b28-554c294a7357 ]
>  at 
> org.apache.drill.common.exceptions.UserException$Builder.build(UserException.java:633)
>  ~[drill-common-1.13.0-SNAPSHOT.jar:1.13.0-SNAPSHOT]
>  at 
> 

[jira] [Commented] (DRILL-6247) Minor fragments remain in CANCELLATION_REQUESTED state after query failure

[Vlad Rozov (JIRA)]

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

Vlad Rozov commented on DRILL-6247:
---

[~khfaraaz] Please take a stack trace after the query is canceled.

> Minor fragments remain in CANCELLATION_REQUESTED state after query failure
> --
>
> Key: DRILL-6247
> URL: https://issues.apache.org/jira/browse/DRILL-6247
> Project: Apache Drill
>  Issue Type: Bug
>  Components: Execution - Flow
>Affects Versions: 1.13.0
>Reporter: Khurram Faraaz
>Assignee: Vlad Rozov
>Priority: Major
> Attachments: 25569e98-10f9-2fe2-9dec-0a42f3ad45fa.sys.drill, 
> cancellation_requested_march_14.png, drillbit_snippet.log, 
> jstack_cancellation_requested.txt
>
>
> Once a query fails, in this case due to an OOM in RPC we see many minor 
> fragments are reported to be in CANCELLATION_REQUESTED state on Web UI after 
> query has failed. The problem is reproducible. drillbit.log for this failure 
> and jstack output are attached here.
> To reproduce the problem on a 4 node cluster.
> alter system reset all;
> alter system set `planner.slice_target`=1;
> Failing query => SELECT * , FLATTEN(arr) FROM many_json_files;
> Drill 1.13.0-SNAPSHOT, commit id: 766315ea17377199897d685ab801edd38394fe01
> Stack trace from output of jstack, fragment 0:0 is reported to be in 
> CANCELLATION_REQUESTED state on Drill Web UI
> jstack -l 13488 > jstack_DRILL_6235.txt
> {noformat}
> "25569e98-10f9-2fe2-9dec-0a42f3ad45fa:frag:0:0" #87 daemon prio=10 os_prio=0 
> tid=0x7f9d01374360 nid=0x2ff5 waiting on condition [0x7f9cd5536000]
>  java.lang.Thread.State: WAITING (parking)
>  at sun.misc.Unsafe.park(Native Method)
>  - parking to wait for <0x0007a388b300> (a 
> org.apache.drill.exec.rpc.ResettableBarrier$InternalSynchronizer)
>  at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>  at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
>  at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997)
>  at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304)
>  at 
> org.apache.drill.exec.rpc.ResettableBarrier.await(ResettableBarrier.java:70)
>  at 
> org.apache.drill.exec.rpc.AbstractRemoteConnection$WriteManager.waitForWritable(AbstractRemoteConnection.java:114)
>  at 
> org.apache.drill.exec.rpc.AbstractRemoteConnection.blockOnNotWritable(AbstractRemoteConnection.java:76)
>  at org.apache.drill.exec.rpc.RpcBus.send(RpcBus.java:108)
>  at 
> org.apache.drill.exec.rpc.user.UserServer$BitToUserConnection.sendData(UserServer.java:275)
>  at 
> org.apache.drill.exec.ops.AccountingUserConnection.sendData(AccountingUserConnection.java:42)
>  at 
> org.apache.drill.exec.physical.impl.ScreenCreator$ScreenRoot.innerNext(ScreenCreator.java:120)
>  at 
> org.apache.drill.exec.physical.impl.BaseRootExec.next(BaseRootExec.java:95)
>  at 
> org.apache.drill.exec.work.fragment.FragmentExecutor$1.run(FragmentExecutor.java:233)
>  at 
> org.apache.drill.exec.work.fragment.FragmentExecutor$1.run(FragmentExecutor.java:226)
>  at java.security.AccessController.doPrivileged(Native Method)
>  at javax.security.auth.Subject.doAs(Subject.java:422)
>  at 
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1595)
>  at 
> org.apache.drill.exec.work.fragment.FragmentExecutor.run(FragmentExecutor.java:226)
>  at 
> org.apache.drill.common.SelfCleaningRunnable.run(SelfCleaningRunnable.java:38)
>  at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>  at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>  at java.lang.Thread.run(Thread.java:748)
> {noformat}
> Stack trace from drillbit.log
> {noformat}
> 2018-03-14 10:52:44,545 [25569e98-10f9-2fe2-9dec-0a42f3ad45fa:frag:1:49] INFO 
> o.a.d.e.w.fragment.FragmentExecutor - User Error Occurred: One or more nodes 
> ran out of memory while executing the query. (Failure allocating buffer.)
> org.apache.drill.common.exceptions.UserException: RESOURCE ERROR: One or more 
> nodes ran out of memory while executing the query.
> Failure allocating buffer.
> [Error Id: b83884df-af31-411a-9b28-554c294a7357 ]
>  at 
> org.apache.drill.common.exceptions.UserException$Builder.build(UserException.java:633)
>  ~[drill-common-1.13.0-SNAPSHOT.jar:1.13.0-SNAPSHOT]
>  at 
> org.apache.drill.exec.work.fragment.FragmentExecutor.run(FragmentExecutor.java:243)
>  [drill-java-exec-1.13.0-SNAPSHOT.jar:1.13.0-SNAPSHOT]
>  at 
> org.apache.drill.common.SelfCleaningRunnable.run(SelfCleaningRunnable.java:38)
>  

[jira] [Commented] (DRILL-5937) prepare.statement.create_timeout_ms default is 10 seconds but code comment says default should be 10 mins

[Kunal Khatua (JIRA)]

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

Kunal Khatua commented on DRILL-5937:
-

Yes. Feel free to create a pull request for this. 

Also, you don't need permission to work on something trivial like this. If 
there is a more complex feature, you can use the Dev mailing list to get 
feedback on your idea before you submit your pull request. 

>  prepare.statement.create_timeout_ms default is 10 seconds but code comment 
> says default should be 10 mins
> --
>
> Key: DRILL-5937
> URL: https://issues.apache.org/jira/browse/DRILL-5937
> Project: Apache Drill
>  Issue Type: Bug
>  Components: Query Planning  Optimization
>Affects Versions: 1.8.0
>Reporter: Pushpendra Jaiswal
>Priority: Major
> Fix For: 1.14.0
>
>
> prepare.statement.create_timeout_ms default is 10 seconds but code comment 
> says default should be 10 mins
> The value is by default set to 1 ms 
> https://github.com/apache/drill/blob/master/exec/java-exec/src/main/java/org/apache/drill/exec/ExecConstants.java#L526
>  
> /**
>* Timeout for create prepare statement request. If the request exceeds 
> this timeout, then request is timed out.
>* Default value is 10mins.
>*/



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

[jira] [Created] (DRILL-6291) Wrong result for COUNT function and empty file (schemaless table)

[Vitalii Diravka (JIRA)]

Vitalii Diravka created DRILL-6291:
--

 Summary: Wrong result for COUNT function and empty file 
(schemaless table)
 Key: DRILL-6291
 URL: https://issues.apache.org/jira/browse/DRILL-6291
 Project: Apache Drill
  Issue Type: Bug
  Components: Functions - Drill
Affects Versions: 1.13.0
Reporter: Vitalii Diravka
 Fix For: Future


The count function shouldn't return null result. For the 0 rows case it should 
always return 0.
{code}
0: jdbc:drill:zk=local> select count(`last_name`) from 
dfs.`/tmp/empty_file.json`;
+-+
| EXPR$0  |
+-+
+-+
No rows selected (0.3 seconds)
{code}
The result should be the similar to:
{code}
0: jdbc:drill:zk=local> select count(`non_existent_column`) from 
cp.`employee.json`;
+-+
| EXPR$0  |
+-+
| 0   |
+-+
1 row selected (0.274 seconds)
{code}

Note: empty_file.json is an empty file.



--
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.

[Hanumath Rao Maduri (JIRA)]

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

Hanumath Rao Maduri commented on DRILL-6212:


[~vvysotskyi] This case should be handled by the chunhui's fix to the similar 
JIRA.

> 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: Volodymyr Vysotskyi
>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-5937) prepare.statement.create_timeout_ms default is 10 seconds but code comment says default should be 10 mins

[Pushpendra Jaiswal (JIRA)]

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

Pushpendra Jaiswal commented on DRILL-5937:
---

Hi [~kkhatua] 

Can I take this up ?

>  prepare.statement.create_timeout_ms default is 10 seconds but code comment 
> says default should be 10 mins
> --
>
> Key: DRILL-5937
> URL: https://issues.apache.org/jira/browse/DRILL-5937
> Project: Apache Drill
>  Issue Type: Bug
>  Components: Query Planning  Optimization
>Affects Versions: 1.8.0
>Reporter: Pushpendra Jaiswal
>Priority: Major
> Fix For: 1.14.0
>
>
> prepare.statement.create_timeout_ms default is 10 seconds but code comment 
> says default should be 10 mins
> The value is by default set to 1 ms 
> https://github.com/apache/drill/blob/master/exec/java-exec/src/main/java/org/apache/drill/exec/ExecConstants.java#L526
>  
> /**
>* Timeout for create prepare statement request. If the request exceeds 
> this timeout, then request is timed out.
>* Default value is 10mins.
>*/



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

[jira] [Commented] (DRILL-6290) Refactor TestInfoSchemaFilterPushDown tests to use PlanTestBase utility methods

[ASF GitHub Bot (JIRA)]

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

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

GitHub user arina-ielchiieva opened a pull request:

https://github.com/apache/drill/pull/1186

DRILL-6290: Refactor TestInfoSchemaFilterPushDown tests to use PlanTestBase 
utility methods

Details in [DRILL-6290](https://issues.apache.org/jira/browse/DRILL-6290).

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/arina-ielchiieva/drill DRILL-6290

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/drill/pull/1186.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1186


commit c08ba0f36028c5e4c23bd3029033b734495295bc
Author: Arina Ielchiieva 
Date:   2018-03-23T11:33:40Z

DRILL-6290: Refactor TestInfoSchemaFilterPushDown tests to use PlanTestBase 
utility methods




> Refactor TestInfoSchemaFilterPushDown tests to use PlanTestBase utility 
> methods
> ---
>
> Key: DRILL-6290
> URL: https://issues.apache.org/jira/browse/DRILL-6290
> Project: Apache Drill
>  Issue Type: Task
>Reporter: Arina Ielchiieva
>Assignee: Arina Ielchiieva
>Priority: Minor
> Fix For: 1.14.0
>
>
> PlanTestBase has useful utility methods to match query plans.
> It would be useful to TestInfoSchemaFilterPushDown to use such utility 
> methods plus loosen expected pattern to match exactly what is needed rather 
> then the whole string.



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

[jira] [Commented] (DRILL-6290) Refactor TestInfoSchemaFilterPushDown tests to use PlanTestBase utility methods

[ASF GitHub Bot (JIRA)]

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

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

Github user arina-ielchiieva commented on the issue:

https://github.com/apache/drill/pull/1186
  
@vdiravka please review.


> Refactor TestInfoSchemaFilterPushDown tests to use PlanTestBase utility 
> methods
> ---
>
> Key: DRILL-6290
> URL: https://issues.apache.org/jira/browse/DRILL-6290
> Project: Apache Drill
>  Issue Type: Task
>Reporter: Arina Ielchiieva
>Assignee: Arina Ielchiieva
>Priority: Minor
> Fix For: 1.14.0
>
>
> PlanTestBase has useful utility methods to match query plans.
> It would be useful to TestInfoSchemaFilterPushDown to use such utility 
> methods plus loosen expected pattern to match exactly what is needed rather 
> then the whole string.



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

[jira] [Updated] (DRILL-6290) Refactor TestInfoSchemaFilterPushDown tests to use PlanTestBase utility methods

[Arina Ielchiieva (JIRA)]

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

Arina Ielchiieva updated DRILL-6290:

Summary: Refactor TestInfoSchemaFilterPushDown tests to use PlanTestBase 
utility methods  (was: Refactor TestInfoSchemaFilterPushDown test to use 
PlanTestBase utility methods)

> Refactor TestInfoSchemaFilterPushDown tests to use PlanTestBase utility 
> methods
> ---
>
> Key: DRILL-6290
> URL: https://issues.apache.org/jira/browse/DRILL-6290
> Project: Apache Drill
>  Issue Type: Task
>Reporter: Arina Ielchiieva
>Assignee: Arina Ielchiieva
>Priority: Minor
> Fix For: 1.14.0
>
>
> PlanTestBase has useful utility methods to match query plans.
> It would be useful to TestInfoSchemaFilterPushDown to use such utility 
> methods plus loosen expected pattern to match exactly what is needed rather 
> then the whole string.



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

[jira] [Created] (DRILL-6290) Refactor TestInfoSchemaFilterPushDown test to use PlanTestBase utility methods

[Arina Ielchiieva (JIRA)]

Arina Ielchiieva created DRILL-6290:
---

 Summary: Refactor TestInfoSchemaFilterPushDown test to use 
PlanTestBase utility methods
 Key: DRILL-6290
 URL: https://issues.apache.org/jira/browse/DRILL-6290
 Project: Apache Drill
  Issue Type: Task
Reporter: Arina Ielchiieva
Assignee: Arina Ielchiieva
 Fix For: 1.14.0


PlanTestBase has useful utility methods to match query plans.
It would be useful to TestInfoSchemaFilterPushDown to use such utility methods 
plus loosen expected pattern to match exactly what is needed rather then the 
whole string.



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

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

[Arina Ielchiieva (JIRA)]

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

Arina Ielchiieva reassigned DRILL-6212:
---

Assignee: Arina Ielchiieva  (was: Volodymyr Vysotskyi)

> 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: Arina Ielchiieva
>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] [Assigned] (DRILL-6212) A simple join is recursing too deep in planning and eventually throwing stack overflow.

[Arina Ielchiieva (JIRA)]

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

Arina Ielchiieva reassigned DRILL-6212:
---

Assignee: Volodymyr Vysotskyi  (was: Hanumath Rao Maduri)

> 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: Volodymyr Vysotskyi
>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] [Assigned] (DRILL-6212) A simple join is recursing too deep in planning and eventually throwing stack overflow.

[Arina Ielchiieva (JIRA)]

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

Arina Ielchiieva reassigned DRILL-6212:
---

Assignee: Volodymyr Vysotskyi  (was: Arina Ielchiieva)

> 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: Volodymyr Vysotskyi
>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-6224) The metrics' page has gauges reset to near zero values and does not seem to update

[ASF GitHub Bot (JIRA)]

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

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

Github user arina-ielchiieva commented on a diff in the pull request:

https://github.com/apache/drill/pull/1160#discussion_r176655100
  
--- Diff: exec/java-exec/src/main/resources/rest/metrics/metrics.ftl ---
@@ -109,18 +114,23 @@
 };
 
 function updateBars(gauges) {
-  $.each(["heap","non-heap","total"], function(i, key) {
+  $.each(["heap","non-heap","total","drill.allocator.root"], 
function(i, key) {
 var used= gauges[key + ".used"].value;
-var max = gauges[key + ".max"].value;
-var usage   = round((used / 1073741824), 2) + "GB";
-var percent = round((used / max), 2);
-
-var styleVal = "width: " + percent + "%;"
-$("#" + key + "Usage").attr({
+var max;
+if (key.startsWith("drill.allocator")) {
--- End diff --

Please address the below comment.


> The metrics' page has gauges reset to near zero values and does not seem to 
> update
> --
>
> Key: DRILL-6224
> URL: https://issues.apache.org/jira/browse/DRILL-6224
> Project: Apache Drill
>  Issue Type: Bug
>  Components: Web Server
>Affects Versions: 1.12.0
>Reporter: Kunal Khatua
>Assignee: Kunal Khatua
>Priority: Major
> Fix For: 1.14.0
>
>
> When viewing http://:8047/metrics#gauges
> The gauges reset to near zero values and does not seem to update.
> Tracing the server calls made, I see the following:
> {code:json}
> {version: "3.0.0", gauges: {G1-Old-Generation.count: {value: 0}, 
> G1-Old-Generation.time: {value: 0},…},…}
> counters :
>   {drill.connections.rpc.control.encrypted: {count: 0},…}
> gauges :
>   {G1-Old-Generation.count: {value: 0}, G1-Old-Generation.time: {value: 0},…}
> histograms :   {,…}
> meters : {}
> timers : {}
> version : "3.0.0"
> {code}
> This looks incorrect and would explain why the metrics appear to be 
> incomplete.



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

[jira] [Assigned] (DRILL-6272) Remove binary jars files from source distribution

[Arina Ielchiieva (JIRA)]

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

Arina Ielchiieva reassigned DRILL-6272:
---

Assignee: Volodymyr Tkach  (was: Arina Ielchiieva)

> Remove binary jars files from source distribution
> -
>
> Key: DRILL-6272
> URL: https://issues.apache.org/jira/browse/DRILL-6272
> Project: Apache Drill
>  Issue Type: Task
>Reporter: Vlad Rozov
>Assignee: Volodymyr Tkach
>Priority: Critical
> Fix For: 1.14.0
>
>
> Per [~vrozov] the source distribution contains binary jar files under 
> exec/java-exec/src/test/resources/jars



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

[jira] [Commented] (DRILL-325) Support for MADlib

[Xiang Lin (JIRA)]

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

Xiang Lin commented on DRILL-325:
-

Hi, I have interest in working on MADlib integration in Drill and I'm moving 
this forward. 

And, I've finished the document according to the [Drill design 
document|https://docs.google.com/document/d/1PnBiOMV5mYBi5N6fLci-bRTva1gieCuxwlSYH9crMhU/edit?usp=sharing](please
 refer to: [MADlib for Apache 
Drill|https://docs.google.com/document/d/1zCraEQnFMPxJE1-B-Yz-_sYLqQSbcHV-AMR2tgRwp_8]).
 More importantly, I've already started the work and have implemented a few 
functions(such as all linear regression functions). Now, I can execute linear 
regression through "linregr_train" and "linregr_predict".

> Support for MADlib
> --
>
> Key: DRILL-325
> URL: https://issues.apache.org/jira/browse/DRILL-325
> Project: Apache Drill
>  Issue Type: New Feature
>Reporter: Michael Hausenblas
>Priority: Major
> Fix For: Future
>
>
> It should be possible to use MADlib (http://doc.madlib.net/latest/) with 
> Drill.



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