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

[ASF GitHub Bot (JIRA)]

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

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

amansinha100 closed pull request #1247: DRILL-6242 Use 
java.time.Local{Date|Time|DateTime} for Drill Date, Time, and Timestamp types
URL: https://github.com/apache/drill/pull/1247
 
 
   

This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:

As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):

diff --git 
a/contrib/storage-hive/core/src/test/java/org/apache/drill/exec/TestHiveDrillNativeParquetReader.java
 
b/contrib/storage-hive/core/src/test/java/org/apache/drill/exec/TestHiveDrillNativeParquetReader.java
index 23c67b5747..fd9701cd16 100644
--- 
a/contrib/storage-hive/core/src/test/java/org/apache/drill/exec/TestHiveDrillNativeParquetReader.java
+++ 
b/contrib/storage-hive/core/src/test/java/org/apache/drill/exec/TestHiveDrillNativeParquetReader.java
@@ -17,14 +17,19 @@
  */
 package org.apache.drill.exec;
 
+import static org.hamcrest.CoreMatchers.containsString;
+import static org.junit.Assert.assertEquals;
+
+import java.math.BigDecimal;
+
 import org.apache.drill.PlanTestBase;
 import org.apache.drill.categories.HiveStorageTest;
 import org.apache.drill.categories.SlowTest;
 import org.apache.drill.common.exceptions.UserRemoteException;
+import org.apache.drill.exec.expr.fn.impl.DateUtility;
 import org.apache.drill.exec.hive.HiveTestBase;
 import org.apache.drill.exec.planner.physical.PlannerSettings;
 import org.hamcrest.CoreMatchers;
-import org.joda.time.DateTime;
 import org.junit.AfterClass;
 import org.junit.BeforeClass;
 import org.junit.Rule;
@@ -32,13 +37,6 @@
 import org.junit.experimental.categories.Category;
 import org.junit.rules.ExpectedException;
 
-import java.math.BigDecimal;
-import java.sql.Date;
-import java.sql.Timestamp;
-
-import static org.hamcrest.CoreMatchers.containsString;
-import static org.junit.Assert.assertEquals;
-
 @Category({SlowTest.class, HiveStorageTest.class})
 public class TestHiveDrillNativeParquetReader extends HiveTestBase {
 
@@ -227,14 +225,14 @@ public void 
testReadAllSupportedHiveDataTypesNativeParquet() throws Exception {
 // There is a regression in Hive 1.2.1 in binary and boolean partition 
columns. Disable for now.
 //"binary_part",
 "boolean_part", "tinyint_part", "decimal0_part", "decimal9_part", 
"decimal18_part", "decimal28_part", "decimal38_part", "double_part", 
"float_part", "int_part", "bigint_part", "smallint_part", "string_part", 
"varchar_part", "timestamp_part", "date_part", "char_part")
-.baselineValues("binaryfield".getBytes(), false, 34, new 
BigDecimal("66"), new BigDecimal("2347.92"), new 
BigDecimal("2758725827.0"), new BigDecimal("29375892739852.8"), new 
BigDecimal("89853749534593985.783"), 8.345d, 4.67f, 123456, 234235L, 3455, 
"stringfield", "varcharfield", new DateTime(Timestamp.valueOf("2013-07-05 
17:01:00").getTime()), "charfield",
+.baselineValues("binaryfield".getBytes(), false, 34, new 
BigDecimal("66"), new BigDecimal("2347.92"), new 
BigDecimal("2758725827.0"), new BigDecimal("29375892739852.8"), new 
BigDecimal("89853749534593985.783"), 8.345d, 4.67f, 123456, 234235L, 3455, 
"stringfield", "varcharfield", DateUtility.parseBest("2013-07-05 17:01:00"), 
"charfield",
 // There is a regression in Hive 1.2.1 in binary and boolean partition 
columns. Disable for now.
 //"binary",
-true, 64, new BigDecimal("37"), new BigDecimal("36.90"), new 
BigDecimal("3289379872.94565"), new BigDecimal("39579334534534.4"), new 
BigDecimal("363945093845093890.900"), 8.345d, 4.67f, 123456, 234235L, 3455, 
"string", "varchar", new DateTime(Timestamp.valueOf("2013-07-05 
17:01:00").getTime()), new DateTime(Date.valueOf("2013-07-05").getTime()), 
"char").baselineValues( // All fields are null, but partition fields have 
non-null values
+true, 64, new BigDecimal("37"), new BigDecimal("36.90"), new 
BigDecimal("3289379872.94565"), new BigDecimal("39579334534534.4"), new 
BigDecimal("363945093845093890.900"), 8.345d, 4.67f, 123456, 234235L, 3455, 
"string", "varchar", DateUtility.parseBest("2013-07-05 17:01:00"), 
DateUtility.parseLocalDate("2013-07-05"), "char").baselineValues( // All fields 
are null, but partition fields have non-null values
 null, null, null, null, null, null, null, null, null, null, null, 
null, null, null, null, null, null,
 // There is a regression in Hive 1.2.1 in binary and boolean partition 
columns. Disable for now.
 //"binary",
-true, 64, new BigDecimal("37"), new BigDecimal("36.90"), new 
BigDecimal("3289379872.94565"), new BigDecimal("39579334534534.4"), new 
BigDecimal("363945093845093890.900"), 8.345d, 

[jira] [Updated] (DRILL-6410) Memory leak in Parquet Reader during cancellation

[salim achouche (JIRA)]

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

salim achouche updated DRILL-6410:
--
Reviewer: Parth Chandra

Created pull request [1257|https://github.com/apache/drill/pull/1257/commits] 
to address this bug.

> Memory leak in Parquet Reader during cancellation
> -
>
> Key: DRILL-6410
> URL: https://issues.apache.org/jira/browse/DRILL-6410
> Project: Apache Drill
>  Issue Type: Bug
>  Components: Storage - Parquet
>Reporter: salim achouche
>Assignee: salim achouche
>Priority: Major
>
> Occasionally, a memory leak is observed within the flat Parquet reader when 
> query cancellation is invoked.



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

[jira] [Commented] (DRILL-6410) Memory leak in Parquet Reader during cancellation

[ASF GitHub Bot (JIRA)]

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

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

sachouche commented on issue #1257: DRILL-6410: Fixed memory leak in flat 
Parquet reader
URL: https://github.com/apache/drill/pull/1257#issuecomment-388509869
 
 
   @parthchandra, can you please review this fix?
   
   Thanks in advance!


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


> Memory leak in Parquet Reader during cancellation
> -
>
> Key: DRILL-6410
> URL: https://issues.apache.org/jira/browse/DRILL-6410
> Project: Apache Drill
>  Issue Type: Bug
>  Components: Storage - Parquet
>Reporter: salim achouche
>Assignee: salim achouche
>Priority: Major
>
> Occasionally, a memory leak is observed within the flat Parquet reader when 
> query cancellation is invoked.



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

[jira] [Commented] (DRILL-6410) Memory leak in Parquet Reader during cancellation

[ASF GitHub Bot (JIRA)]

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

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

sachouche opened a new pull request #1257: DRILL-6410: Fixed memory leak in 
flat Parquet reader
URL: https://github.com/apache/drill/pull/1257
 
 
   **Problem Description**
   - Occasionally, a memory leak is observed within the Parquet reader (flat) 
when query cancellation is invoked
   - I tried a previous attempt to address this issue but it seems it is still 
happening
   - Thus far, only QA have been able to observe this issue (and only 
occasionally)
   
   **Analysis**
   - There was a recent breakthrough which gives me hope for addressing this 
issue 
   - The leak logged two piece of information: leak size and state of the child 
allocator
   - The state of the child allocator indicated no leak (all allocated bytes 
released)
   - After code examination, it occurred to me this was happening because the 
Asynchronous Page Reader task was releasing the Drill buffer while the scan 
thread was closing the allocator
   - The code attempts to cancel asynchronous tasks and then release allocated 
buffers, though there is one big issue: the Java FutureTask.cancel(true) 
doesn't block during the cancellation process; this method **merely interrupts 
the asynchronous task** and proceeds
   - This means if the asynchronous thread was context switched or doing 
computation (not blocked waiting), then the fragment cleanup logic can close 
the allocator before all resources have been released
   
   **Fix**
   - The Java ThreadPoolExecutor and FutureTask have few extension points to 
enhance the task termination process
   - Created a new utility class which can create an ExecutorService with the 
ability to block during future cancellation
   - Blocking will happen only when the cancel method is allowed to interrupt 
the asynchronous task
   - Note that there shouldn't be any performance degradation as 
synchronization code was added only to cover the cancel path
   - Also added a new test-suite to test the correctness of this new utility
   
   
   


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


> Memory leak in Parquet Reader during cancellation
> -
>
> Key: DRILL-6410
> URL: https://issues.apache.org/jira/browse/DRILL-6410
> Project: Apache Drill
>  Issue Type: Bug
>  Components: Storage - Parquet
>Reporter: salim achouche
>Assignee: salim achouche
>Priority: Major
>
> Occasionally, a memory leak is observed within the flat Parquet reader when 
> query cancellation is invoked.



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

[jira] [Created] (DRILL-6411) Make batch memory sizing logs uniform across all operators

[Padma Penumarthy (JIRA)]

Padma Penumarthy created DRILL-6411:
---

 Summary: Make batch memory sizing logs uniform across all operators
 Key: DRILL-6411
 URL: https://issues.apache.org/jira/browse/DRILL-6411
 Project: Apache Drill
  Issue Type: Bug
Affects Versions: 1.13.0
Reporter: Padma Penumarthy
Assignee: Padma Penumarthy
 Fix For: 1.14.0


Make batch memory sizing logs uniform across all operators so QA can parse and 
verify easily. 



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

[jira] [Created] (DRILL-6410) Memory leak in Parquet Reader during cancellation

[salim achouche (JIRA)]

salim achouche created DRILL-6410:
-

 Summary: Memory leak in Parquet Reader during cancellation
 Key: DRILL-6410
 URL: https://issues.apache.org/jira/browse/DRILL-6410
 Project: Apache Drill
  Issue Type: Bug
  Components: Storage - Parquet
Reporter: salim achouche
Assignee: salim achouche


Occasionally, a memory leak is observed within the flat Parquet reader when 
query cancellation is invoked.



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

[jira] [Closed] (DRILL-3584) Drill Kerberos HDFS Support / Documentation

[Krystal (JIRA)]

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

Krystal closed DRILL-3584.
--
Resolution: Fixed

> Drill Kerberos HDFS Support / Documentation
> ---
>
> Key: DRILL-3584
> URL: https://issues.apache.org/jira/browse/DRILL-3584
> Project: Apache Drill
>  Issue Type: New Feature
>Affects Versions: 1.1.0
>Reporter: Hari Sekhon
>Priority: Critical
>  Labels: security
>
> I'm trying to find Drill docs for Kerberos support for secure HDFS clusters 
> and it doesn't appear to be well tested / supported / documented yet.
> This product is Dead-on-Arrival if it doesn't integrate well with secure 
> Hadoop clusters, specifically HDFS + Kerberos (plus obviously secure 
> kerberized Hive/HCatalog etc.)



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

[jira] [Commented] (DRILL-3584) Drill Kerberos HDFS Support / Documentation

[Krystal (JIRA)]

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

Krystal commented on DRILL-3584:


Tested the steps mentioned by Sudheesh against cloudera cdh 5.13 vm and got 
drill working with Kerberos enabled. 

> Drill Kerberos HDFS Support / Documentation
> ---
>
> Key: DRILL-3584
> URL: https://issues.apache.org/jira/browse/DRILL-3584
> Project: Apache Drill
>  Issue Type: New Feature
>Affects Versions: 1.1.0
>Reporter: Hari Sekhon
>Priority: Critical
>  Labels: security
>
> I'm trying to find Drill docs for Kerberos support for secure HDFS clusters 
> and it doesn't appear to be well tested / supported / documented yet.
> This product is Dead-on-Arrival if it doesn't integrate well with secure 
> Hadoop clusters, specifically HDFS + Kerberos (plus obviously secure 
> kerberized Hive/HCatalog etc.)



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

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

[ASF GitHub Bot (JIRA)]

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

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

amansinha100 commented on issue #1225: DRILL-6272: Refactor dynamic UDFs and 
function initializer tests to g…
URL: https://github.com/apache/drill/pull/1225#issuecomment-388500821
 
 
   @arina-ielchiieva I encountered some merge conflicts.  Can you pls rebase on 
master ? 


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


> 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: Arina Ielchiieva
>Priority: Critical
>  Labels: ready-to-commit
> 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-6364) WebUI does not cleanly handle shutdown and state toggling when Drillbits go on and offline

[ASF GitHub Bot (JIRA)]

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

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

amansinha100 closed pull request #1241: DRILL-6364: Handle Cluster Info in 
WebUI when existing/new bits restart
URL: https://github.com/apache/drill/pull/1241
 
 
   

This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:

As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):

diff --git 
a/exec/java-exec/src/main/java/org/apache/drill/exec/server/rest/DrillRoot.java 
b/exec/java-exec/src/main/java/org/apache/drill/exec/server/rest/DrillRoot.java
index 50d99b0446..0a48801037 100644
--- 
a/exec/java-exec/src/main/java/org/apache/drill/exec/server/rest/DrillRoot.java
+++ 
b/exec/java-exec/src/main/java/org/apache/drill/exec/server/rest/DrillRoot.java
@@ -88,7 +88,7 @@ public Response getDrillbitStatus() {
 Collection drillbits = getClusterInfoJSON().getDrillbits();
 Map drillStatusMap = new HashMap();
 for (DrillbitInfo drillbit : drillbits) {
-  drillStatusMap.put(drillbit.getAddress() + "-" + drillbit.getUserPort(), 
drillbit.getState());
+  drillStatusMap.put(drillbit.getAddress() + "-" + drillbit.getHttpPort(), 
drillbit.getState());
 }
 return setResponse(drillStatusMap);
   }
@@ -239,6 +239,7 @@ private Response setResponse(Map entity) {
   private Response shutdown(String resp) throws Exception {
 Map shutdownInfo = new HashMap();
 new Thread(new Runnable() {
+@Override
 public void run() {
   try {
 drillbit.close();
diff --git a/exec/java-exec/src/main/resources/rest/index.ftl 
b/exec/java-exec/src/main/resources/rest/index.ftl
index 5259e44bba..11d1dd21a0 100644
--- a/exec/java-exec/src/main/resources/rest/index.ftl
+++ b/exec/java-exec/src/main/resources/rest/index.ftl
@@ -54,9 +54,11 @@
 
   
 
-  Drillbits ${model.getDrillbits()?size}
+  Drillbits ${model.getDrillbits()?size}
+  
+  
   
-
+
   
 
   #
@@ -71,9 +73,7 @@
   Version
   Status
   Uptime
-  <#if (model.shouldShowAdminInfo() || !model.isAuthEnabled()) >
-  Shutdown
-  
+  Shutdown
 
   
   
@@ -103,14 +103,14 @@
 
 ${drillbit.getState()}
 Not Available
-  
-<#if ( model.shouldShowAdminInfo() &&  ( drillbit.isCurrent() 
|| ( !model.isAuthEnabled() && location.protocol != "https" ))) >
-  
+
+<#if (model.isAuthEnabled() && !model.shouldShowAdminInfo())>
+  
 <#else>
-  
+  
 
   
-  
+
   
   
   <#assign i = i + 1>
@@ -217,21 +217,34 @@
   
   

-  var updateRemoteInfo = <#if 
(model.isAuthEnabled())>false<#else>true;
   var refreshTime = 1;
+  var nAText = "Not Available";
   var refresh = getRefreshTime();
   var timeout;
   var size = $("#size").html();
   reloadMetrics();
   setInterval(reloadMetrics, refreshTime);
+  var hideShutdownBtns = setShutdownCtrl();
+
+  //Hide Shutdown buttons for remote HTTPS entries
+  function setShutdownCtrl() {
+for (i = 1; i <= size; i++) {
+  let currentRow = $("#row-"+i);
+  if ( location.protocol == "https:" && 
(currentRow.find("#current").html() != "Current") ) {
+//Hide Shutdown Button for remote nodes with HTTPS enabled
+currentRow.find(".shutdownCtrl").css('display','none');
+  }
+}
+  }
 
+  //Gets a refresh time for graceful shutdown
   function getRefreshTime() {
   $.ajax({
   type: 'GET',
   url: '/gracePeriod',
   dataType: "json",
   complete: function (data) {
-  var gracePeriod = data.responseJSON["gracePeriod"];
+  let gracePeriod = data.responseJSON["gracePeriod"];
   if (gracePeriod > 0) {
   refreshTime = gracePeriod / 3;
   }
@@ -240,8 +253,9 @@
   });
   }
 
+  //Periodic reload of status of Drillbits
   function reloadStatus () {
-  var result = $.ajax({
+  let result = $.ajax({
   type: 'GET',
   url: '/state',
   dataType: "json",
@@ -252,37 +266,161 @@
   timeout = 

[jira] [Commented] (DRILL-6401) Precision for decimal data types may be lost for the case when cast with literal is used

[ASF GitHub Bot (JIRA)]

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

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

amansinha100 closed pull request #1254: DRILL-6401: Precision for decimal data 
types may be lost for the case…
URL: https://github.com/apache/drill/pull/1254
 
 
   

This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:

As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):

diff --git 
a/exec/java-exec/src/main/java/org/apache/drill/exec/planner/logical/DrillOptiq.java
 
b/exec/java-exec/src/main/java/org/apache/drill/exec/planner/logical/DrillOptiq.java
index fd791dd7f3..2cd60688c5 100644
--- 
a/exec/java-exec/src/main/java/org/apache/drill/exec/planner/logical/DrillOptiq.java
+++ 
b/exec/java-exec/src/main/java/org/apache/drill/exec/planner/logical/DrillOptiq.java
@@ -550,7 +550,9 @@ public LogicalExpression visitLiteral(RexLiteral literal) {
 literal.getType().getScale(),
 literal.getType().getPrecision()));
   }
-  return ValueExpressions.getVarDecimal((BigDecimal) 
literal.getValue());
+  return ValueExpressions.getVarDecimal((BigDecimal) 
literal.getValue(),
+  literal.getType().getPrecision(),
+  literal.getType().getScale());
 }
 double dbl = ((BigDecimal) literal.getValue()).doubleValue();
 logger.warn("Converting exact decimal into approximate decimal.\n" +
diff --git 
a/exec/java-exec/src/main/java/org/apache/drill/exec/store/parquet/ParquetFilterBuilder.java
 
b/exec/java-exec/src/main/java/org/apache/drill/exec/store/parquet/ParquetFilterBuilder.java
index 52c47230e0..e55425e948 100644
--- 
a/exec/java-exec/src/main/java/org/apache/drill/exec/store/parquet/ParquetFilterBuilder.java
+++ 
b/exec/java-exec/src/main/java/org/apache/drill/exec/store/parquet/ParquetFilterBuilder.java
@@ -181,7 +181,9 @@ private LogicalExpression 
getValueExpressionFromConst(ValueHolder holder, TypePr
   VarDecimalHolder decimalHolder = (VarDecimalHolder) holder;
   return ValueExpressions.getVarDecimal(
   DecimalUtility.getBigDecimalFromDrillBuf(decimalHolder.buffer,
-  decimalHolder.start, decimalHolder.end - decimalHolder.start, 
decimalHolder.scale));
+  decimalHolder.start, decimalHolder.end - decimalHolder.start, 
decimalHolder.scale),
+  decimalHolder.precision,
+  decimalHolder.scale);
 case DATE:
   return ValueExpressions.getDate(((DateHolder) holder).value);
 case TIMESTAMP:
diff --git 
a/logical/src/main/java/org/apache/drill/common/expression/ValueExpressions.java
 
b/logical/src/main/java/org/apache/drill/common/expression/ValueExpressions.java
index 29e9c05197..2ef809aaef 100644
--- 
a/logical/src/main/java/org/apache/drill/common/expression/ValueExpressions.java
+++ 
b/logical/src/main/java/org/apache/drill/common/expression/ValueExpressions.java
@@ -110,8 +110,8 @@ public static LogicalExpression getDecimal38(BigDecimal i) {
   return new Decimal38Expression(i, ExpressionPosition.UNKNOWN);
   }
 
-  public static LogicalExpression getVarDecimal(BigDecimal i) {
-return new VarDecimalExpression(i, ExpressionPosition.UNKNOWN);
+  public static LogicalExpression getVarDecimal(BigDecimal input, int 
precision, int scale) {
+return new VarDecimalExpression(input, precision, scale, 
ExpressionPosition.UNKNOWN);
   }
 
   public static LogicalExpression getNumericExpression(String sign, String s, 
ExpressionPosition ep) {
@@ -403,11 +403,15 @@ public MajorType getMajorType() {
 
   public static class VarDecimalExpression extends LogicalExpressionBase {
 
-private BigDecimal bigDecimal;
+private final BigDecimal bigDecimal;
+private final int precision;
+private final int scale;
 
-public VarDecimalExpression(BigDecimal input, ExpressionPosition pos) {
+public VarDecimalExpression(BigDecimal input, int precision, int scale, 
ExpressionPosition pos) {
   super(pos);
   this.bigDecimal = input;
+  this.precision = precision;
+  this.scale = scale;
 }
 
 public BigDecimal getBigDecimal() {
@@ -419,8 +423,8 @@ public MajorType getMajorType() {
   return MajorType
   .newBuilder()
   .setMinorType(MinorType.VARDECIMAL)
-  .setScale(bigDecimal.scale())
-  .setPrecision(bigDecimal.precision())
+  .setScale(scale)
+  .setPrecision(precision)
   .setMode(DataMode.REQUIRED)
   .build();
 }


 


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.
 

[jira] [Commented] (DRILL-6249) Add Markdown Docs for Unit Testing and Link to it in README.md

[ASF GitHub Bot (JIRA)]

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

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

amansinha100 closed pull request #1251: DRILL-6249: Adding more unit testing 
documentation.
URL: https://github.com/apache/drill/pull/1251
 
 
   

This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:

As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):

diff --git a/README.md b/README.md
index a30cf07f16..f2b5b9d5d9 100644
--- a/README.md
+++ b/README.md
@@ -20,7 +20,10 @@ Please see the [Apache Drill 
Website](http://drill.apache.org/) or the [Apache D
 
 
 ## Join the community!
-Apache Drill is an Apache Foundation project and is seeking all types of 
contributions.  Please say hello on the Apache Drill mailing list or join our 
Google Hangouts for more information.  (More information can be found at the 
Apache Drill website).
+Apache Drill is an Apache Foundation project and is seeking all types of 
contributions.
+Please say hello on the [Apache Drill mailing 
list](http://drill.apache.org/mailinglists/)
+or join our [Google Hangouts](http://drill.apache.org/community-resources/) 
for more information.
+(More information can be found at the [Apache Drill 
website](http://drill.apache.org/)).
 
 ## Export Control
 This distribution includes cryptographic software. The country in which you 
currently reside may have restrictions on the import, possession, use, and/or 
re-export to another country, of encryption software. BEFORE using any 
encryption software, please check your country's laws, regulations and policies 
concerning the import, possession, or use, and re-export of encryption 
software, to see if this is permitted. See  for more 
information.  
diff --git a/common/src/test/java/org/apache/drill/test/DirTestWatcher.java 
b/common/src/test/java/org/apache/drill/test/DirTestWatcher.java
index 271ac940d1..6bdc9519f9 100644
--- a/common/src/test/java/org/apache/drill/test/DirTestWatcher.java
+++ b/common/src/test/java/org/apache/drill/test/DirTestWatcher.java
@@ -31,10 +31,10 @@
  * 
  *
  * 
- * A {@link DirTestWatcher} is added to a test by declaring it as a JUnit 
{@link org.junit.Rule}. A {@link org.junit.Rule} is
- * a piece of code that is run before and after every JUnit test marked with 
the {@link org.junit.Test} annotation. When the
+ * A {@link DirTestWatcher} is added to a test by declaring it as a JUnit 
{@link org.junit.Rule}. A {@link org.junit.Rule Rule} is
+ * a piece of code that is run before and after every JUnit test marked with 
the {@link org.junit.Test Test} annotation. When the
  * {@link DirTestWatcher} is added to a test class the {@link DirTestWatcher} 
will create a temp directory before each of your
- * {@link org.junit.Test}s and optionally delete the temp directory after each 
of your {@link org.junit.Test}s. The temp directory
+ * {@link org.junit.Test Test}s and optionally delete the temp directory after 
each of your {@link org.junit.Test Test}s. The base temp directory
  * created by the {@link DirTestWatcher} is in the target folder of the 
maven project and has the form
  * (my test class fully qualified name)/(my test method name). So in 
the context of the code example below, the temp directory created for
  * each test in target will be my.proj.MyTestClass/myTestMethod1 
and my.proj.MyTestClass/myTestMethod2 respectively.
@@ -46,7 +46,7 @@
  * 
  *
  * 
- * By default, the {@link DirTestWatcher} deletes the temp directory it 
creates at the end of each {@link org.junit.Test}. However, you can create a 
{@link DirTestWatcher}
+ * By default, the {@link DirTestWatcher} deletes the temp directory it 
creates at the end of each {@link org.junit.Test Test}. However, you can create 
a {@link DirTestWatcher}
  * by doing {@code new DirTestWatcher(false)} to disable the deletion of temp 
directories after a test. This is useful if you want to examine files after a 
test runs.
  * 
  *
@@ -54,16 +54,16 @@
  * package my.proj;
  *
  * public class MyTestClass {
- *   org.junit.Rule
+ *   Rule
  *   public final DirTestWatcher dirTestWatcher = new DirTestWatcher();
  *
- *   org.junit.Test
+ *   Test
  *   public void myTestMethod1() {
  * File dir = dirTestWatcher.getDir();
  * // Do stuff in the temp directory
  *   }
  *
- *   org.junit.Test
+ *   Test
  *   public void myTestMethod2() {
  * File dir = dirTestWatcher.getDir();
  * // Do stuff in the temp directory
diff --git a/common/src/test/java/org/apache/drill/test/TestTools.java 
b/common/src/test/java/org/apache/drill/test/TestTools.java
index 661b978d65..8cf7ca7c42 100644
--- a/common/src/test/java/org/apache/drill/test/TestTools.java
+++ 

[jira] [Commented] (DRILL-6321) Lateral Join: Planning changes - enable submitting physical plan

[ASF GitHub Bot (JIRA)]

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

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

amansinha100 closed pull request #1224: DRILL-6321: Customize Drill's 
conformance. Allow support to APPLY key…
URL: https://github.com/apache/drill/pull/1224
 
 
   

This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:

As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):

diff --git 
a/exec/java-exec/src/main/java/org/apache/drill/exec/planner/sql/DrillConformance.java
 
b/exec/java-exec/src/main/java/org/apache/drill/exec/planner/sql/DrillConformance.java
new file mode 100644
index 00..e6efeb92d1
--- /dev/null
+++ 
b/exec/java-exec/src/main/java/org/apache/drill/exec/planner/sql/DrillConformance.java
@@ -0,0 +1,43 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements.  See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership.  The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License.  You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.drill.exec.planner.sql;
+
+import org.apache.calcite.sql.validate.SqlConformanceEnum;
+import org.apache.calcite.sql.validate.SqlDelegatingConformance;
+
+/**
+ * Drill's SQL conformance is SqlConformanceEnum.DEFAULT except for method 
isApplyAllowed().
+ * Since Drill is going to allow OUTER APPLY and CROSS APPLY to allow each row 
from left child of Join
+ * to join with output of right side (sub-query or table function that will be 
invoked for each row).
+ * Refer to DRILL-5999 for more information.
+ */
+public class DrillConformance extends SqlDelegatingConformance {
+
+  public DrillConformance() {
+super(SqlConformanceEnum.DEFAULT);
+  }
+
+  public DrillConformance(SqlConformanceEnum flavor) {
+super(flavor);
+  }
+
+  @Override
+  public boolean isApplyAllowed() {
+return true;
+  }
+}
diff --git 
a/exec/java-exec/src/main/java/org/apache/drill/exec/planner/sql/DrillParserConfig.java
 
b/exec/java-exec/src/main/java/org/apache/drill/exec/planner/sql/DrillParserConfig.java
index 1f67c5e161..575ad8610f 100644
--- 
a/exec/java-exec/src/main/java/org/apache/drill/exec/planner/sql/DrillParserConfig.java
+++ 
b/exec/java-exec/src/main/java/org/apache/drill/exec/planner/sql/DrillParserConfig.java
@@ -22,7 +22,6 @@
 import org.apache.calcite.sql.parser.SqlParser;
 import org.apache.calcite.sql.parser.SqlParserImplFactory;
 import org.apache.calcite.sql.validate.SqlConformance;
-import org.apache.calcite.sql.validate.SqlConformanceEnum;
 import org.apache.drill.exec.planner.physical.PlannerSettings;
 import 
org.apache.drill.exec.planner.sql.parser.impl.DrillParserWithCompoundIdConverter;
 
@@ -30,6 +29,7 @@
 
   private final long identifierMaxLength;
   private final Quoting quotingIdentifiers;
+  public final static SqlConformance DRILL_CONFORMANCE = new 
DrillConformance();
 
   public DrillParserConfig(PlannerSettings settings) {
 identifierMaxLength = settings.getIdentifierMaxLength();
@@ -63,7 +63,7 @@ public boolean caseSensitive() {
 
   @Override
   public SqlConformance conformance() {
-return SqlConformanceEnum.DEFAULT;
+return DRILL_CONFORMANCE;
   }
 
   @Override
diff --git 
a/exec/java-exec/src/main/java/org/apache/drill/exec/planner/sql/SqlConverter.java
 
b/exec/java-exec/src/main/java/org/apache/drill/exec/planner/sql/SqlConverter.java
index 69362d9392..d9ead8b78b 100644
--- 
a/exec/java-exec/src/main/java/org/apache/drill/exec/planner/sql/SqlConverter.java
+++ 
b/exec/java-exec/src/main/java/org/apache/drill/exec/planner/sql/SqlConverter.java
@@ -31,6 +31,7 @@
 import org.apache.calcite.config.CalciteConnectionProperty;
 import org.apache.calcite.jdbc.DynamicSchema;
 import org.apache.calcite.jdbc.JavaTypeFactoryImpl;
+import org.apache.calcite.plan.Contexts;
 import org.apache.calcite.plan.ConventionTraitDef;
 import org.apache.calcite.plan.RelOptCluster;
 import org.apache.calcite.plan.RelOptCostFactory;
@@ -58,6 +59,7 @@
 import org.apache.calcite.sql.parser.SqlParserPos;
 import org.apache.calcite.sql.type.SqlTypeName;
 import org.apache.calcite.sql.util.ChainedSqlOperatorTable;
+import 

[jira] [Commented] (DRILL-6364) WebUI does not cleanly handle shutdown and state toggling when Drillbits go on and offline

[ASF GitHub Bot (JIRA)]

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

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

amansinha100 commented on issue #1241: DRILL-6364: Handle Cluster Info in WebUI 
when existing/new bits restart
URL: https://github.com/apache/drill/pull/1241#issuecomment-388496718
 
 
   +1 


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


> WebUI does not cleanly handle shutdown and state toggling when Drillbits go 
> on and offline
> --
>
> Key: DRILL-6364
> URL: https://issues.apache.org/jira/browse/DRILL-6364
> Project: Apache Drill
>  Issue Type: Bug
>  Components: Web Server
>Reporter: Kunal Khatua
>Assignee: Kunal Khatua
>Priority: Major
>  Labels: ready-to-commit
> Fix For: 1.14.0
>
>
> When the webpage is loaded the first time, the shutdown button is enabled by 
> default, which might not be correct, since scenarios like HTTPS, etc does not 
> support this for remote bits. (i.e the user needs to navigate to that node's 
> UI for shutting it down). 
> Similarly, when a previously unseen Drillbit comes online, the node will not 
> be rendered until the page is refreshed by the user. 
> Lastly, if the node from whom the UI page was served goes down, the status 
> update for the rest of the cluster is not updated.



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

[jira] [Commented] (DRILL-6375) ANY_VALUE aggregate function

[ASF GitHub Bot (JIRA)]

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

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

vvysotskyi commented on a change in pull request #1256: DRILL-6375 : Support 
for ANY_VALUE aggregate function
URL: https://github.com/apache/drill/pull/1256#discussion_r187726925
 
 

 ##
 File path: 
exec/java-exec/src/main/java/org/apache/drill/exec/vector/complex/MapUtility.java
 ##
 @@ -228,11 +228,301 @@ public static void writeToMapFromReader(FieldReader 
fieldReader, BaseWriter.MapW
   
fieldReader.copyAsValue(mapWriter.list(MappifyUtility.fieldValue).list());
   break;
 default:
-  throw new DrillRuntimeException(String.format("kvgen does not 
support input of type: %s", valueMinorType));
+  throw new DrillRuntimeException(String.format(caller
+  + " does not support input of type: %s", valueMinorType));
   }
 } catch (ClassCastException e) {
   final MaterializedField field = fieldReader.getField();
-  throw new DrillRuntimeException(String.format(TYPE_MISMATCH_ERROR, 
field.getName(), field.getType()));
+  throw new DrillRuntimeException(String.format(caller + 
TYPE_MISMATCH_ERROR, field.getName(), field.getType()));
+}
+  }
+
+  public static void writeToMapFromReader(FieldReader fieldReader, 
BaseWriter.MapWriter mapWriter,
 
 Review comment:
   Could you please add support for `VARDECIMAL` type, implement `ANY_VALUE` 
aggregate function for this type and add a test for decimals also?


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


> ANY_VALUE aggregate function
> 
>
> Key: DRILL-6375
> URL: https://issues.apache.org/jira/browse/DRILL-6375
> Project: Apache Drill
>  Issue Type: New Feature
>  Components: Functions - Drill
>Affects Versions: 1.13.0
>Reporter: Gautam Kumar Parai
>Assignee: Gautam Kumar Parai
>Priority: Major
> Fix For: 1.14.0
>
>
> We had discussions on the Apache Calcite [1] and Apache Drill [2] mailing 
> lists regarding an equivalent for DISTINCT ON. The community seems to prefer 
> the ANY_VALUE. This Jira is a placeholder for implementing the ANY_VALUE 
> aggregate function in Apache Drill. We should also eventually contribute it 
> to Apache Calcite.
> [1]https://lists.apache.org/thread.html/f2007a489d3a5741875bcc8a1edd8d5c3715e5114ac45058c3b3a42d@%3Cdev.calcite.apache.org%3E
> [2]https://lists.apache.org/thread.html/2517eef7410aed4e88b9515f7e4256335215c1ad39a2676a08d21cb9@%3Cdev.drill.apache.org%3E



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

[jira] [Commented] (DRILL-6375) ANY_VALUE aggregate function

[ASF GitHub Bot (JIRA)]

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

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

gparai opened a new pull request #1256: DRILL-6375 : Support for ANY_VALUE 
aggregate function
URL: https://github.com/apache/drill/pull/1256
 
 
   This PR is for adding support for ANY_VALUE aggregate function. The support 
is currently add for Streaming Aggregate. Hash Aggregate will be supported in a 
follow up 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


> ANY_VALUE aggregate function
> 
>
> Key: DRILL-6375
> URL: https://issues.apache.org/jira/browse/DRILL-6375
> Project: Apache Drill
>  Issue Type: New Feature
>  Components: Functions - Drill
>Affects Versions: 1.13.0
>Reporter: Gautam Kumar Parai
>Assignee: Gautam Kumar Parai
>Priority: Major
> Fix For: 1.14.0
>
>
> We had discussions on the Apache Calcite [1] and Apache Drill [2] mailing 
> lists regarding an equivalent for DISTINCT ON. The community seems to prefer 
> the ANY_VALUE. This Jira is a placeholder for implementing the ANY_VALUE 
> aggregate function in Apache Drill. We should also eventually contribute it 
> to Apache Calcite.
> [1]https://lists.apache.org/thread.html/f2007a489d3a5741875bcc8a1edd8d5c3715e5114ac45058c3b3a42d@%3Cdev.calcite.apache.org%3E
> [2]https://lists.apache.org/thread.html/2517eef7410aed4e88b9515f7e4256335215c1ad39a2676a08d21cb9@%3Cdev.drill.apache.org%3E



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

[jira] [Commented] (DRILL-6409) Query Failed: An Error Occurred

[Volodymyr Vysotskyi (JIRA)]

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

Volodymyr Vysotskyi commented on DRILL-6409:


[~judilson], could you please share a query which throws this error and stack 
trace with the error from the log. Also, please share details about the version 
where it is reproduced. If it is master, please share its commit id.

> Query Failed: An Error Occurred
> ---
>
> Key: DRILL-6409
> URL: https://issues.apache.org/jira/browse/DRILL-6409
> Project: Apache Drill
>  Issue Type: Bug
>Reporter: JUDILSON JOSE DA COSTA JUNIOR
>Priority: Major
> Attachments: erro_drill.png
>
>
> h2. Query Failed: An Error Occurred
> org.apache.drill.common.exceptions.UserRemoteException: INTERNAL_ERROR ERROR: 
> UnSupported Bson type: DECIMAL128 Fragment 0:0 [Error Id: 
> 35c951e0-3ce7-4232-8a90-1c146ecc749f on DSK-0244.eicon.com.br:31010]
> Verison mongo-java-driver: 3.7.0
> Version mongo: 3.4



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

[jira] [Updated] (DRILL-6409) Query Failed: An Error Occurred

[JUDILSON JOSE DA COSTA JUNIOR (JIRA)]

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

JUDILSON JOSE DA COSTA JUNIOR updated DRILL-6409:
-
Description: 
h2. Query Failed: An Error Occurred

org.apache.drill.common.exceptions.UserRemoteException: INTERNAL_ERROR ERROR: 
UnSupported Bson type: DECIMAL128 Fragment 0:0 [Error Id: 
35c951e0-3ce7-4232-8a90-1c146ecc749f on DSK-0244.eicon.com.br:31010]

Verison mongo-java-driver: 3.7.0

Version mongo: 3.4

  was:
h2. Query Failed: An Error Occurred

org.apache.drill.common.exceptions.UserRemoteException: INTERNAL_ERROR ERROR: 
UnSupported Bson type: DECIMAL128 Fragment 0:0 [Error Id: 
35c951e0-3ce7-4232-8a90-1c146ecc749f on DSK-0244.eicon.com.br:31010]

Version mongo: 3.4


> Query Failed: An Error Occurred
> ---
>
> Key: DRILL-6409
> URL: https://issues.apache.org/jira/browse/DRILL-6409
> Project: Apache Drill
>  Issue Type: Bug
>Reporter: JUDILSON JOSE DA COSTA JUNIOR
>Priority: Major
> Attachments: erro_drill.png
>
>
> h2. Query Failed: An Error Occurred
> org.apache.drill.common.exceptions.UserRemoteException: INTERNAL_ERROR ERROR: 
> UnSupported Bson type: DECIMAL128 Fragment 0:0 [Error Id: 
> 35c951e0-3ce7-4232-8a90-1c146ecc749f on DSK-0244.eicon.com.br:31010]
> Verison mongo-java-driver: 3.7.0
> Version mongo: 3.4



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

[jira] [Updated] (DRILL-6409) Query Failed: An Error Occurred

[JUDILSON JOSE DA COSTA JUNIOR (JIRA)]

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

JUDILSON JOSE DA COSTA JUNIOR updated DRILL-6409:
-
Attachment: erro_drill.png

> Query Failed: An Error Occurred
> ---
>
> Key: DRILL-6409
> URL: https://issues.apache.org/jira/browse/DRILL-6409
> Project: Apache Drill
>  Issue Type: Bug
>Reporter: JUDILSON JOSE DA COSTA JUNIOR
>Priority: Major
> Attachments: erro_drill.png
>
>
> h2. Query Failed: An Error Occurred
> org.apache.drill.common.exceptions.UserRemoteException: INTERNAL_ERROR ERROR: 
> UnSupported Bson type: DECIMAL128 Fragment 0:0 [Error Id: 
> 35c951e0-3ce7-4232-8a90-1c146ecc749f on DSK-0244.eicon.com.br:31010]
> Verison mongo-java-driver: 3.7.0
> Version mongo: 3.4



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

[jira] [Updated] (DRILL-6409) Query Failed: An Error Occurred

[JUDILSON JOSE DA COSTA JUNIOR (JIRA)]

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

JUDILSON JOSE DA COSTA JUNIOR updated DRILL-6409:
-
Description: 
h2. Query Failed: An Error Occurred

org.apache.drill.common.exceptions.UserRemoteException: INTERNAL_ERROR ERROR: 
UnSupported Bson type: DECIMAL128 Fragment 0:0 [Error Id: 
35c951e0-3ce7-4232-8a90-1c146ecc749f on DSK-0244.eicon.com.br:31010]

Version mongo: 3.4

  was:
h2. Query Failed: An Error Occurred

org.apache.drill.common.exceptions.UserRemoteException: INTERNAL_ERROR ERROR: 
UnSupported Bson type: DECIMAL128 Fragment 0:0 [Error Id: 
35c951e0-3ce7-4232-8a90-1c146ecc749f on DSK-0244.eicon.com.br:31010]


> Query Failed: An Error Occurred
> ---
>
> Key: DRILL-6409
> URL: https://issues.apache.org/jira/browse/DRILL-6409
> Project: Apache Drill
>  Issue Type: Bug
>Reporter: JUDILSON JOSE DA COSTA JUNIOR
>Priority: Major
>
> h2. Query Failed: An Error Occurred
> org.apache.drill.common.exceptions.UserRemoteException: INTERNAL_ERROR ERROR: 
> UnSupported Bson type: DECIMAL128 Fragment 0:0 [Error Id: 
> 35c951e0-3ce7-4232-8a90-1c146ecc749f on DSK-0244.eicon.com.br:31010]
> Version mongo: 3.4



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

[jira] [Created] (DRILL-6409) Query Failed: An Error Occurred

[JUDILSON JOSE DA COSTA JUNIOR (JIRA)]

JUDILSON JOSE DA COSTA JUNIOR created DRILL-6409:


 Summary: Query Failed: An Error Occurred
 Key: DRILL-6409
 URL: https://issues.apache.org/jira/browse/DRILL-6409
 Project: Apache Drill
  Issue Type: Bug
Reporter: JUDILSON JOSE DA COSTA JUNIOR


h2. Query Failed: An Error Occurred

org.apache.drill.common.exceptions.UserRemoteException: INTERNAL_ERROR ERROR: 
UnSupported Bson type: DECIMAL128 Fragment 0:0 [Error Id: 
35c951e0-3ce7-4232-8a90-1c146ecc749f on DSK-0244.eicon.com.br:31010]



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

[jira] [Commented] (DRILL-6321) Lateral Join: Planning changes - enable submitting physical plan

[ASF GitHub Bot (JIRA)]

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

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

amansinha100 commented on issue #1224: DRILL-6321: Customize Drill's 
conformance. Allow support to APPLY key…
URL: https://github.com/apache/drill/pull/1224#issuecomment-388422123
 
 
   Jumping in late here..I see the PR has 2 +1s and possibly a -0 from Vlad :-) 
  In this case it seems the anonymous class would have been sufficient for the 
current requirements but since the debate is more about the design pattern 
rather than functionality, I am inclined to commit this 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


> Lateral Join: Planning changes - enable submitting physical plan
> 
>
> Key: DRILL-6321
> URL: https://issues.apache.org/jira/browse/DRILL-6321
> Project: Apache Drill
>  Issue Type: Task
>Reporter: Parth Chandra
>Assignee: Chunhui Shi
>Priority: Major
>  Labels: ready-to-commit
> Fix For: 1.14.0
>
>
> Implement changes to enable submitting a physical plan containing lateral and 
> unnest.



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

[jira] [Commented] (DRILL-6408) Document Drill API /cluster.json states

[Hari Sekhon (JIRA)]

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

Hari Sekhon commented on DRILL-6408:


Looks like the states can be found here:

https://github.com/apache/drill/blob/master/exec/java-exec/src/main/java/org/apache/drill/exec/server/DrillbitStateManager.java#L25

> Document Drill API /cluster.json states
> ---
>
> Key: DRILL-6408
> URL: https://issues.apache.org/jira/browse/DRILL-6408
> Project: Apache Drill
>  Issue Type: Improvement
>  Components:  Server, Client - HTTP, Documentation, Execution - 
> Monitoring, Tools, Build  Test
>Affects Versions: 1.13.0
> Environment: MapR 6.0 / Apache Drill in Docker
>Reporter: Hari Sekhon
>Priority: Major
>
> Request to document the possible states returned by Drill API's newer 
> /cluster.json endpoint:
> [https://drill.apache.org/docs/rest-api-introduction/#get-/cluster.json]
> Real world output shows an interesting 'state' field which is currently 
> undocumented in the link above, but you can see here:
> {code:java}
> {
>   "drillbits" : [ {
>     "address" : "1939919665a9",
>     "userPort" : "31010",
>     "controlPort" : "31011",
>     "dataPort" : "31012",
>     "version" : "1.13.0",
>     "current" : true,
>     "versionMatch" : true,
>     "state" : "ONLINE"
>   } ],
>   "currentVersion" : "1.13.0",
>   "mismatchedVersions" : [ ],
>   "userEncryptionEnabled" : false,
>   "bitEncryptionEnabled" : false,
>   "authEnabled" : false
> }{code}



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

[jira] [Created] (DRILL-6408) Document Drill API /cluster.json states

[Hari Sekhon (JIRA)]

Hari Sekhon created DRILL-6408:
--

 Summary: Document Drill API /cluster.json states
 Key: DRILL-6408
 URL: https://issues.apache.org/jira/browse/DRILL-6408
 Project: Apache Drill
  Issue Type: Improvement
  Components:  Server, Client - HTTP, Documentation, Execution - 
Monitoring, Tools, Build  Test
Affects Versions: 1.13.0
 Environment: Request to document the possible states returned by Drill 
API's newer /cluster.json endpoint:

[https://drill.apache.org/docs/rest-api-introduction/#get-/cluster.json]

Real world output shows an interesting 'state' field which is currently 
undocumented in the link above, but you can see here:
{code:java}
{
  "drillbits" : [ {
    "address" : "1939919665a9",
    "userPort" : "31010",
    "controlPort" : "31011",
    "dataPort" : "31012",
    "version" : "1.13.0",
    "current" : true,
    "versionMatch" : true,
    "state" : "ONLINE"
  } ],
  "currentVersion" : "1.13.0",
  "mismatchedVersions" : [ ],
  "userEncryptionEnabled" : false,
  "bitEncryptionEnabled" : false,
  "authEnabled" : false
}
{code}
Reporter: Hari Sekhon


MapR 6.0 / Apache Drill in Docker



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

[jira] [Comment Edited] (DRILL-6407) Document API /status responses, currently only "Running" is shown in docs

[Hari Sekhon (JIRA)]

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

Hari Sekhon edited comment on DRILL-6407 at 5/11/18 2:52 PM:
-

Looking at

[https://github.com/apache/drill/blob/master/exec/java-exec/src/main/java/org/apache/drill/exec/server/rest/StatusResources.java#L75|http://example.com/]

I'm not sure there are other statuses but I'm not familiar with the internals 
of the code base and don't want to spend too much time on this.

Suffice it to say, there should be different statuses reflecting the true 
condition of Drill, see DRILL-6406 and DRILL-5990, and they should be clearly 
documented.

Right now if "Running" is the only thing that the /status API will ever output 
then under what conditions would say /status be blank or return 404 or 500?

 


was (Author: harisekhon):
Looking at

[https://github.com/apache/drill/blob/master/exec/java-exec/src/main/java/org/apache/drill/exec/server/rest/StatusResources.java#L75|http://example.com/]

I'm not sure there are other statuses but I'm not familiar with the internals 
of the code base and don't want to spend too much time on this.

Suffice it to say, there should be different statuses reflecting the true 
condition of Drill, see DRILL-6406 and DRILL-5990, and they should be clearly 
documented.

Right now if Running is the only thing that the /status API will ever output 
then under what conditions would say /status be blank or return 404 or 500?

 

> Document API /status responses, currently only "Running" is shown in docs
> -
>
> Key: DRILL-6407
> URL: https://issues.apache.org/jira/browse/DRILL-6407
> Project: Apache Drill
>  Issue Type: Improvement
>  Components: Client - HTTP, Documentation
>Affects Versions: 1.10.0, 1.11.0, 1.13.0
> Environment: MapR Enterprise 5.2 / 6.0
>Reporter: Hari Sekhon
>Priority: Major
>
> Request to document the results of the API /status endpoint. Currently only 
> the "Running" result is shown in the docs here:
> https://drill.apache.org/docs/rest-api-introduction/#get-/status



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

[jira] [Comment Edited] (DRILL-6407) Document API /status responses, currently only "Running" is shown in docs

[Hari Sekhon (JIRA)]

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

Hari Sekhon edited comment on DRILL-6407 at 5/11/18 2:52 PM:
-

Looking at

[https://github.com/apache/drill/blob/master/exec/java-exec/src/main/java/org/apache/drill/exec/server/rest/StatusResources.java#L75|http://example.com/]

I'm not sure there are other statuses but I'm not familiar with the internals 
of the code base and don't want to spend too much time on this.

Suffice it to say, there should be different statuses reflecting the true 
condition of Drill, see DRILL-6406 and DRILL-5990, and they should be clearly 
documented.

Right now if Running is the only thing that the /status API will ever output 
then under what conditions would say /status be blank or return 404 or 500?

 


was (Author: harisekhon):
Looking at

[https://github.com/apache/drill/blob/master/exec/java-exec/src/main/java/org/apache/drill/exec/server/rest/StatusResources.java#L75|http://example.com]

I'm not sure there are other statuses but I'm not familiar with the internals 
of the code base and don't want to spend too much time on this.

Suffice to say there should be different statuses reflecting the true condition 
of Drill, see DRILL-6406 and DRILL-5990

 

> Document API /status responses, currently only "Running" is shown in docs
> -
>
> Key: DRILL-6407
> URL: https://issues.apache.org/jira/browse/DRILL-6407
> Project: Apache Drill
>  Issue Type: Improvement
>  Components: Client - HTTP, Documentation
>Affects Versions: 1.10.0, 1.11.0, 1.13.0
> Environment: MapR Enterprise 5.2 / 6.0
>Reporter: Hari Sekhon
>Priority: Major
>
> Request to document the results of the API /status endpoint. Currently only 
> the "Running" result is shown in the docs here:
> https://drill.apache.org/docs/rest-api-introduction/#get-/status



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

[jira] [Commented] (DRILL-6407) Document API /status responses, currently only "Running" is shown in docs

[Hari Sekhon (JIRA)]

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

Hari Sekhon commented on DRILL-6407:


Looking at

[https://github.com/apache/drill/blob/master/exec/java-exec/src/main/java/org/apache/drill/exec/server/rest/StatusResources.java#L75|http://example.com]

I'm not sure there are other statuses but I'm not familiar with the internals 
of the code base and don't want to spend too much time on this.

Suffice to say there should be different statuses reflecting the true condition 
of Drill, see DRILL-6406 and DRILL-5990

 

> Document API /status responses, currently only "Running" is shown in docs
> -
>
> Key: DRILL-6407
> URL: https://issues.apache.org/jira/browse/DRILL-6407
> Project: Apache Drill
>  Issue Type: Improvement
>  Components: Client - HTTP, Documentation
>Affects Versions: 1.10.0, 1.11.0, 1.13.0
> Environment: MapR Enterprise 5.2 / 6.0
>Reporter: Hari Sekhon
>Priority: Major
>
> Request to document the results of the API /status endpoint. Currently only 
> the "Running" result is shown in the docs here:
> https://drill.apache.org/docs/rest-api-introduction/#get-/status



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

[jira] [Updated] (DRILL-6407) Document API /status responses, currently only "Running" is shown in docs

[Hari Sekhon (JIRA)]

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

Hari Sekhon updated DRILL-6407:
---
Summary: Document API /status responses, currently only "Running" is shown 
in docs  (was: Document API /status possible responses other then "Running")

> Document API /status responses, currently only "Running" is shown in docs
> -
>
> Key: DRILL-6407
> URL: https://issues.apache.org/jira/browse/DRILL-6407
> Project: Apache Drill
>  Issue Type: Improvement
>  Components: Client - HTTP, Documentation
>Affects Versions: 1.10.0, 1.11.0, 1.13.0
> Environment: MapR Enterprise 5.2 / 6.0
>Reporter: Hari Sekhon
>Priority: Major
>
> Request to document the results of the API /status endpoint. Currently only 
> the "Running" result is shown in the docs here:
> https://drill.apache.org/docs/rest-api-introduction/#get-/status



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

[jira] [Created] (DRILL-6407) Document API /status possible responses other then "Running"

[Hari Sekhon (JIRA)]

Hari Sekhon created DRILL-6407:
--

 Summary: Document API /status possible responses other then 
"Running"
 Key: DRILL-6407
 URL: https://issues.apache.org/jira/browse/DRILL-6407
 Project: Apache Drill
  Issue Type: Improvement
  Components: Client - HTTP, Documentation
Affects Versions: 1.13.0, 1.11.0, 1.10.0
 Environment: MapR Enterprise 5.2 / 6.0
Reporter: Hari Sekhon


Request to document the results of the API /status endpoint. Currently only the 
"Running" result is shown in the docs here:

https://drill.apache.org/docs/rest-api-introduction/#get-/status



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

[jira] [Updated] (DRILL-6406) Apache Drill API /status unreliable - add Proper Health Check to API - /status returns "Running" even though Drill isn't usable eg. java classpath errors for flexjson-*.j

[Hari Sekhon (JIRA)]

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

Hari Sekhon updated DRILL-6406:
---
Summary: Apache Drill API /status unreliable - add Proper Health Check to 
API - /status returns "Running" even though Drill isn't usable eg. java 
classpath errors for flexjson-*.jar when trying to execute any query  (was: 
Apache Drill /status unreliable - add Proper Health Check to API - /status 
returns "Running" even though Drill isn't usable eg. java classpath errors for 
flexjson-*.jar when trying to execute any query)

> Apache Drill API /status unreliable - add Proper Health Check to API - 
> /status returns "Running" even though Drill isn't usable eg. java classpath 
> errors for flexjson-*.jar when trying to execute any query
> -
>
> Key: DRILL-6406
> URL: https://issues.apache.org/jira/browse/DRILL-6406
> Project: Apache Drill
>  Issue Type: Bug
>  Components:  Server, Client - HTTP, Execution - Monitoring, Tools, 
> Build  Test, Web Server
>Affects Versions: 1.10.0, 1.13.0
> Environment: MapR Enterprise 5.2 / 6.0
>Reporter: Hari Sekhon
>Priority: Major
>
> I've come across situations on MapR 5.2 / 6.0 where Drill 1.10 / 1.13 is up 
> and running but there are flexjson jar classpath errors meaning that Drill is 
> not usable so queries fail even though the API gives the impression that 
> Drill is available. This is bad for load balancers.
> This API needs to be much more robust and terms of checking if Drill is fully 
> working. I suggest internally doing a health check real query and if that 
> executes successfully and returns the expected result, only then updating the 
> status to OK / Running.
> This internal health check query should be periodically re-executed (eg. 
> every 30 secs) and the status set to ERROR or something if if fails.



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

[jira] [Updated] (DRILL-6406) Apache Drill /status unreliable - add Proper Health Check to API - /status returns "Running" even though Drill isn't usable eg. java classpath errors for flexjson-*.jar w

[Hari Sekhon (JIRA)]

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

Hari Sekhon updated DRILL-6406:
---
Environment: MapR Enterprise 5.2 / 6.0

> Apache Drill /status unreliable - add Proper Health Check to API - /status 
> returns "Running" even though Drill isn't usable eg. java classpath errors 
> for flexjson-*.jar when trying to execute any query
> -
>
> Key: DRILL-6406
> URL: https://issues.apache.org/jira/browse/DRILL-6406
> Project: Apache Drill
>  Issue Type: Bug
>  Components:  Server, Client - HTTP, Execution - Monitoring, Tools, 
> Build  Test, Web Server
>Affects Versions: 1.10.0, 1.13.0
> Environment: MapR Enterprise 5.2 / 6.0
>Reporter: Hari Sekhon
>Priority: Major
>
> I've come across situations on MapR 5.2 / 6.0 where Drill 1.10 / 1.13 is up 
> and running but there are flexjson jar classpath errors meaning that Drill is 
> not usable so queries fail even though the API gives the impression that 
> Drill is available. This is bad for load balancers.
> This API needs to be much more robust and terms of checking if Drill is fully 
> working. I suggest internally doing a health check real query and if that 
> executes successfully and returns the expected result, only then updating the 
> status to OK / Running.
> This internal health check query should be periodically re-executed (eg. 
> every 30 secs) and the status set to ERROR or something if if fails.



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

[jira] [Updated] (DRILL-6406) Apache Drill /status unreliable - add Proper Health Check to API - /status returns "Running" even though Drill isn't usable eg. java classpath errors for flexjson-*.jar w

[Hari Sekhon (JIRA)]

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

Hari Sekhon updated DRILL-6406:
---
Summary: Apache Drill /status unreliable - add Proper Health Check to API - 
/status returns "Running" even though Drill isn't usable eg. java classpath 
errors for flexjson-*.jar when trying to execute any query  (was: Apache Drill 
Add Proper Health Check to API - /status returns "Running" even though Drill 
isn't usable eg. java classpath errors for flexjson-*.jar when trying to 
execute any query)

> Apache Drill /status unreliable - add Proper Health Check to API - /status 
> returns "Running" even though Drill isn't usable eg. java classpath errors 
> for flexjson-*.jar when trying to execute any query
> -
>
> Key: DRILL-6406
> URL: https://issues.apache.org/jira/browse/DRILL-6406
> Project: Apache Drill
>  Issue Type: Bug
>  Components:  Server, Client - HTTP, Execution - Monitoring, Tools, 
> Build  Test, Web Server
>Affects Versions: 1.10.0, 1.13.0
>Reporter: Hari Sekhon
>Priority: Major
>
> I've come across situations on MapR 5.2 / 6.0 where Drill 1.10 / 1.13 is up 
> and running but there are flexjson jar classpath errors meaning that Drill is 
> not usable so queries fail even though the API gives the impression that 
> Drill is available. This is bad for load balancers.
> This API needs to be much more robust and terms of checking if Drill is fully 
> working. I suggest internally doing a health check real query and if that 
> executes successfully and returns the expected result, only then updating the 
> status to OK / Running.
> This internal health check query should be periodically re-executed (eg. 
> every 30 secs) and the status set to ERROR or something if if fails.



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

[jira] [Updated] (DRILL-5990) Apache Drill /status API returns OK ('Running') even with JRE while queries will not work - make status API reflect the fact that Drill is broken on JRE or stop Drill sta

[Hari Sekhon (JIRA)]

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

Hari Sekhon updated DRILL-5990:
---
Component/s: Query Planning & Optimization

> Apache Drill /status API returns OK ('Running') even with JRE while queries 
> will not work - make status API reflect the fact that Drill is broken on JRE 
> or stop Drill starting up with JRE
> ---
>
> Key: DRILL-5990
> URL: https://issues.apache.org/jira/browse/DRILL-5990
> Project: Apache Drill
>  Issue Type: Bug
>  Components:  Server, Client - HTTP, Execution - Monitoring, Query 
> Planning  Optimization
>Affects Versions: 1.10.0, 1.11.0
> Environment: Docker
>Reporter: Hari Sekhon
>Assignee: Venkata Jyothsna Donapati
>Priority: Major
>
> If running Apache Drill on versions 1.10 / 1.11 on JRE it appears that 
> queries no longer run without JDK, but the /status monitoring API endpoint 
> does not reflect the fact the Apache Drill will not work and still returns 
> 'Running'.
> While 'Running' is technically true the process is up, it's effectively 
> broken and Apache Drill should either reflect this in /status that is is 
> broken or refuse to start up on JRE altogether.
> See this ticket for more information:
> https://github.com/HariSekhon/Dockerfiles/pull/15



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

[jira] [Updated] (DRILL-6406) Apache Drill Add Proper Health Check to API - /status returns "Running" even though Drill isn't usable eg. java classpath errors for flexjson-*.jar when trying to execute

[Hari Sekhon (JIRA)]

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

Hari Sekhon updated DRILL-6406:
---
Issue Type: Bug  (was: Improvement)

> Apache Drill Add Proper Health Check to API - /status returns "Running" even 
> though Drill isn't usable eg. java classpath errors for flexjson-*.jar when 
> trying to execute any query
> 
>
> Key: DRILL-6406
> URL: https://issues.apache.org/jira/browse/DRILL-6406
> Project: Apache Drill
>  Issue Type: Bug
>  Components:  Server, Client - HTTP, Execution - Monitoring, Tools, 
> Build  Test, Web Server
>Affects Versions: 1.10.0, 1.13.0
>Reporter: Hari Sekhon
>Priority: Major
>
> I've come across situations on MapR 5.2 / 6.0 where Drill 1.10 / 1.13 is up 
> and running but there are flexjson jar classpath errors meaning that Drill is 
> not usable so queries fail even though the API gives the impression that 
> Drill is available. This is bad for load balancers.
> This API needs to be much more robust and terms of checking if Drill is fully 
> working. I suggest internally doing a health check real query and if that 
> executes successfully and returns the expected result, only then updating the 
> status to OK / Running.
> This internal health check query should be periodically re-executed (eg. 
> every 30 secs) and the status set to ERROR or something if if fails.



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

[jira] [Created] (DRILL-6406) Apache Drill Add Proper Health Check to API - /status returns "Running" even though Drill isn't usable eg. java classpath errors for flexjson-*.jar when trying to execute

[Hari Sekhon (JIRA)]

Hari Sekhon created DRILL-6406:
--

 Summary: Apache Drill Add Proper Health Check to API - /status 
returns "Running" even though Drill isn't usable eg. java classpath errors for 
flexjson-*.jar when trying to execute any query
 Key: DRILL-6406
 URL: https://issues.apache.org/jira/browse/DRILL-6406
 Project: Apache Drill
  Issue Type: Improvement
  Components:  Server, Client - HTTP, Execution - Monitoring, Tools, 
Build  Test, Web Server
Affects Versions: 1.13.0, 1.10.0
Reporter: Hari Sekhon


I've come across situations on MapR 5.2 / 6.0 where Drill 1.10 / 1.13 is up and 
running but there are flexjson jar classpath errors meaning that Drill is not 
usable so queries fail even though the API gives the impression that Drill is 
available. This is bad for load balancers.

This API needs to be much more robust and terms of checking if Drill is fully 
working. I suggest internally doing a health check real query and if that 
executes successfully and returns the expected result, only then updating the 
status to OK / Running.

This internal health check query should be periodically re-executed (eg. every 
30 secs) and the status set to ERROR or something if if fails.



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

[jira] [Updated] (DRILL-6255) Drillbit while sending control message to itself creates a connection instead of submitting locally

[Arina Ielchiieva (JIRA)]

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

Arina Ielchiieva updated DRILL-6255:

Reviewer: Arina Ielchiieva

> Drillbit while sending control message to itself creates a connection instead 
> of submitting locally
> ---
>
> Key: DRILL-6255
> URL: https://issues.apache.org/jira/browse/DRILL-6255
> Project: Apache Drill
>  Issue Type: Bug
>  Components: Execution - Flow
>Affects Versions: 1.12.0
>Reporter: Sorabh Hamirwasia
>Assignee: Sorabh Hamirwasia
>Priority: Major
> Fix For: 1.14.0
>
>
> With the new shutdown feature introduced in 1.12, there is a state introduced 
> in DrillbitEndpoint. Due to this the equality check happening 
> [here|https://github.com/apache/drill/blob/master/exec/java-exec/src/main/java/org/apache/drill/exec/work/foreman/FragmentsRunner.java#L256]
>  will result in false and hence the fragments supposed to be scheduled on 
> Foreman will be treated as remote fragments and a connection will be created 
> to schedule it. The equality check is false because localEndpoint state is 
> STARTUP whereas state in assigned Drillbit is ONLINE.
> I guess now we should update the equality check to verify just for address 
> and control port to be same between assigned and local Drillbit endpoint. A 
> test can be added for this based on _sys.memory_ table since that guarantees 
> scheduling minor fragments on each Drillbit node.



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

[jira] [Updated] (DRILL-4525) Query with BETWEEN clause on Date and Timestamp values fails with Validation Error

[Arina Ielchiieva (JIRA)]

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

Arina Ielchiieva updated DRILL-4525:

Fix Version/s: 1.14.0

> Query with BETWEEN clause on Date and Timestamp values fails with Validation 
> Error
> --
>
> Key: DRILL-4525
> URL: https://issues.apache.org/jira/browse/DRILL-4525
> Project: Apache Drill
>  Issue Type: Bug
>  Components: Query Planning  Optimization
>Reporter: Abhishek Girish
>Assignee: Bohdan Kazydub
>Priority: Critical
> Fix For: 1.14.0
>
>
> Query: (simplified variant of TPC-DS Query37)
> {code}
> SELECT
>*
> FROM   
>date_dim
> WHERE   
>d_date BETWEEN Cast('1999-03-06' AS DATE) AND  (
>   Cast('1999-03-06' AS DATE) + INTERVAL '60' day)
> LIMIT 10;
> {code}
> Error:
> {code}
> Error: VALIDATION ERROR: From line 6, column 8 to line 7, column 64: Cannot 
> apply 'BETWEEN ASYMMETRIC' to arguments of type ' BETWEEN ASYMMETRIC 
>  AND '. Supported form(s): ' BETWEEN 
>  AND '
> SQL Query null
> [Error Id: 223fb37c-f561-4a37-9283-871dc6f4d6d0 on abhi2:31010] 
> (state=,code=0)
> {code}
> This is a regression from 1.6.0. 



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

[jira] [Updated] (DRILL-4525) Query with BETWEEN clause on Date and Timestamp values fails with Validation Error

[Arina Ielchiieva (JIRA)]

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

Arina Ielchiieva updated DRILL-4525:

Issue Type: Improvement  (was: Bug)

> Query with BETWEEN clause on Date and Timestamp values fails with Validation 
> Error
> --
>
> Key: DRILL-4525
> URL: https://issues.apache.org/jira/browse/DRILL-4525
> Project: Apache Drill
>  Issue Type: Improvement
>  Components: Query Planning  Optimization
>Reporter: Abhishek Girish
>Assignee: Bohdan Kazydub
>Priority: Critical
> Fix For: 1.14.0
>
>
> Query: (simplified variant of TPC-DS Query37)
> {code}
> SELECT
>*
> FROM   
>date_dim
> WHERE   
>d_date BETWEEN Cast('1999-03-06' AS DATE) AND  (
>   Cast('1999-03-06' AS DATE) + INTERVAL '60' day)
> LIMIT 10;
> {code}
> Error:
> {code}
> Error: VALIDATION ERROR: From line 6, column 8 to line 7, column 64: Cannot 
> apply 'BETWEEN ASYMMETRIC' to arguments of type ' BETWEEN ASYMMETRIC 
>  AND '. Supported form(s): ' BETWEEN 
>  AND '
> SQL Query null
> [Error Id: 223fb37c-f561-4a37-9283-871dc6f4d6d0 on abhi2:31010] 
> (state=,code=0)
> {code}
> This is a regression from 1.6.0. 



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

[jira] [Assigned] (DRILL-4525) Query with BETWEEN clause on Date and Timestamp values fails with Validation Error

[Arina Ielchiieva (JIRA)]

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

Arina Ielchiieva reassigned DRILL-4525:
---

Assignee: Bohdan Kazydub  (was: Sean Hsuan-Yi Chu)

> Query with BETWEEN clause on Date and Timestamp values fails with Validation 
> Error
> --
>
> Key: DRILL-4525
> URL: https://issues.apache.org/jira/browse/DRILL-4525
> Project: Apache Drill
>  Issue Type: Bug
>  Components: Query Planning  Optimization
>Reporter: Abhishek Girish
>Assignee: Bohdan Kazydub
>Priority: Critical
> Fix For: 1.14.0
>
>
> Query: (simplified variant of TPC-DS Query37)
> {code}
> SELECT
>*
> FROM   
>date_dim
> WHERE   
>d_date BETWEEN Cast('1999-03-06' AS DATE) AND  (
>   Cast('1999-03-06' AS DATE) + INTERVAL '60' day)
> LIMIT 10;
> {code}
> Error:
> {code}
> Error: VALIDATION ERROR: From line 6, column 8 to line 7, column 64: Cannot 
> apply 'BETWEEN ASYMMETRIC' to arguments of type ' BETWEEN ASYMMETRIC 
>  AND '. Supported form(s): ' BETWEEN 
>  AND '
> SQL Query null
> [Error Id: 223fb37c-f561-4a37-9283-871dc6f4d6d0 on abhi2:31010] 
> (state=,code=0)
> {code}
> This is a regression from 1.6.0. 



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

[jira] [Updated] (DRILL-6401) Precision for decimal data types may be lost for the case when cast with literal is used

[Arina Ielchiieva (JIRA)]

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

Arina Ielchiieva updated DRILL-6401:

Labels: ready-to-commit  (was: )

> Precision for decimal data types may be lost for the case when cast with 
> literal is used
> 
>
> Key: DRILL-6401
> URL: https://issues.apache.org/jira/browse/DRILL-6401
> Project: Apache Drill
>  Issue Type: Bug
>Reporter: Volodymyr Vysotskyi
>Assignee: Volodymyr Vysotskyi
>Priority: Major
>  Labels: ready-to-commit
> Fix For: 1.14.0
>
>
> For the case when cast with decimal literal is used and literal has less 
> precision than specified in the casting type:
> {code:sql}
> SELECT cast('999.99' as decimal(9, 4)) decimal_9_4
> {code}
> the precision in column metadata is incorrect: 7, but should be 9.
> Test which has the similar check 
> {{PreparedStatementTest.testQueryMetadataInPreparedStatement}} is failed when 
> it is ran separately. 



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

[jira] [Updated] (DRILL-6401) Precision for decimal data types may be lost for the case when cast with literal is used

[Arina Ielchiieva (JIRA)]

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

Arina Ielchiieva updated DRILL-6401:

Reviewer: Arina Ielchiieva

> Precision for decimal data types may be lost for the case when cast with 
> literal is used
> 
>
> Key: DRILL-6401
> URL: https://issues.apache.org/jira/browse/DRILL-6401
> Project: Apache Drill
>  Issue Type: Bug
>Reporter: Volodymyr Vysotskyi
>Assignee: Volodymyr Vysotskyi
>Priority: Major
> Fix For: 1.14.0
>
>
> For the case when cast with decimal literal is used and literal has less 
> precision than specified in the casting type:
> {code:sql}
> SELECT cast('999.99' as decimal(9, 4)) decimal_9_4
> {code}
> the precision in column metadata is incorrect: 7, but should be 9.
> Test which has the similar check 
> {{PreparedStatementTest.testQueryMetadataInPreparedStatement}} is failed when 
> it is ran separately. 



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