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

2018-03-22 Thread ASF GitHub Bot (JIRA) 

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

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

Github user kkhatua commented on the issue:

https://github.com/apache/drill/pull/1160
  
@arina-ielchiieva 
Restricting this PR to address the bug in `metrics.ftl`
Will create a new PR for 
[DRILL-6289](https://issues.apache.org/jira/browse/DRILL-6289)


> 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] [Created] (DRILL-6289) Cluster view should show more relevant information

2018-03-22 Thread Kunal Khatua (JIRA) 
Kunal Khatua created DRILL-6289:
---

 Summary: Cluster view should show more relevant information
 Key: DRILL-6289
 URL: https://issues.apache.org/jira/browse/DRILL-6289
 Project: Apache Drill
  Issue Type: Improvement
  Components: Web Server
Affects Versions: 1.13.0
Reporter: Kunal Khatua
Assignee: Kunal Khatua
 Fix For: 1.14.0


When fixing DRILL-6224, I noticed that the same information can be very useful 
to have in the cluster view shown on a Drillbit's homepage. 

The proposal is to show the following:
# Heap Memory in use
# Direct Memory (actively) in use - Since we're not able to get the total 
memory held by Netty at the moment, but only what is currently allocated to 
running queries
# Process CPU
# Average (System) Load Factor 

Information such as the port numbers don't help much during general cluster 
health, so it might be worth removing this information if more real-estate is 
needed.




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

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

2018-03-22 Thread ASF GitHub Bot (JIRA) 

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

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

GitHub user vrozov opened a pull request:

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

DRILL-6288: Upgrade org.javassist:javassist and org.reflections:reflections

@vdiravka Please review

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

$ git pull https://github.com/vrozov/drill DRILL-6288

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

https://github.com/apache/drill/pull/1185.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 #1185


commit d6b74d59af0cb8fa39b3deb73846a3b45acddfba
Author: Vlad Rozov 
Date:   2018-03-22T22:47:31Z

DRILL-6288: Upgrade org.javassist:javassist and org.reflections:reflections




> 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-6242) Output format for nested date, time, timestamp values in an object hierarchy

2018-03-22 Thread Jiang Wu (JIRA) 

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

Jiang Wu commented on DRILL-6242:
-

[https://github.com/apache/drill/pull/1184]

 
 * Updated to use java.sql.Date, java.sql.Time, and java.sql.Timestamp to 
represent their corresponding Date, Time, Timestamp drill types.
 * No loss to precision as the java.sql versions are simple subclass to 
java.util.Date with millisecond precisions.
 * With typed java classes, we can then display them in the command line 
correctly through custom JSON serializers in JsonStringArrayList and 
JsonStringHashMap.  The custom serializer uses the same formatter for Date, 
Time, and Timestamp from DateUtility class.  This is the same formatter used 
for Json outputs.  So the results shown in a command line should be consistent 
with the results inside a CTAS json output file.
 * Many tweaks to Test*** where date, time, timestamps are used.  Did not 
change the way these test methods generate the time using joda DateTime class.  
Simply convert the generated DateTime object to java.sql.* version as 
appropriate.  This preserves the existing logic. 

 

> 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-6242) Output format for nested date, time, timestamp values in an object hierarchy

2018-03-22 Thread ASF GitHub Bot (JIRA) 

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

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

GitHub user jiang-wu opened a pull request:

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

DRILL-6242 - Use java.sql.[Date|Time|Timestamp] classes to hold value…

See Jira ticket for details.  Use java.sql.Date, java.sql.Time, and 
java.sql.Timestamp as the Java representation for their corresponding Drill 
types.  This does not lose any precisions as these classes are just simple 
subclasses of java.util.Date with millisecond precision.  But using these 
classes allows the command line to properly format the data using 
org.apache.drill.exec.util.JsonStringArrayList and 
org.apache.drill.exec.util.JsonStringHashMap.

The changes are simple enough.  But many Test** methods need to be updated 
to use java.sql.Date|Time|Timestamp.  Opt not to optimize these changes.  
Places still use joda DateTime to parse date and time as before, but then 
converted to the java.sql.Date|Time|Timestamp as appropriate.  

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

$ git pull https://github.com/jiang-wu/drill DRILL-6242-master

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

https://github.com/apache/drill/pull/1184.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 #1184


commit 7cbb8b81196732cb223c031cd629d9bc941640d9
Author: Jiang Wu 
Date:   2018-03-22T20:42:20Z

DRILL-6242 - Use java.sql.[Date|Time|Timestamp] classes to hold values from 
corresponding Drill date, time, and timestamp types.




> 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] [Updated] (DRILL-6280) Cleanup execution of BuildTimeScan during maven build

2018-03-22 Thread Vitalii Diravka (JIRA) 

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

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

> Cleanup execution of BuildTimeScan during maven build
> -
>
> Key: DRILL-6280
> URL: https://issues.apache.org/jira/browse/DRILL-6280
> Project: Apache Drill
>  Issue Type: Improvement
>Reporter: Vlad Rozov
>Assignee: Vlad Rozov
>Priority: Minor
>  Labels: ready-to-commit
>
> {{exec:java}} has a dependency on {{logback-classic}} that is only available 
> in {{test}} scope.
> {noformat}
> [INFO] --- exec-maven-plugin:1.2.1:java (default) @ drill-common ---
> SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
> SLF4J: Defaulting to no-operation (NOP) logger implementation
> SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further 
> details.
> {noformat}



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

[jira] [Commented] (DRILL-6280) Cleanup execution of BuildTimeScan during maven build

2018-03-22 Thread ASF GitHub Bot (JIRA) 

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

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

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

https://github.com/apache/drill/pull/1177#discussion_r176608901
  
--- Diff: exec/java-exec/pom.xml ---
@@ -828,31 +828,9 @@
   
 
   
-   
+  
 org.codehaus.mojo
 exec-maven-plugin
-1.2.1
-
-  
-org.apache.drill
-drill-common
-${project.version}
-tests
-  
-
-
-  
-process-classes
-java
-  
-
-
-  
org.apache.drill.common.scanner.BuildTimeScan
-  true
--- End diff --

This is a nice move. 
I asked about ``, but you have already answered 
above, we just use project dependencies for now.


> Cleanup execution of BuildTimeScan during maven build
> -
>
> Key: DRILL-6280
> URL: https://issues.apache.org/jira/browse/DRILL-6280
> Project: Apache Drill
>  Issue Type: Improvement
>Reporter: Vlad Rozov
>Assignee: Vlad Rozov
>Priority: Minor
>
> {{exec:java}} has a dependency on {{logback-classic}} that is only available 
> in {{test}} scope.
> {noformat}
> [INFO] --- exec-maven-plugin:1.2.1:java (default) @ drill-common ---
> SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
> SLF4J: Defaulting to no-operation (NOP) logger implementation
> SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further 
> details.
> {noformat}



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

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

2018-03-22 Thread Vlad Rozov (JIRA) 

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

Vlad Rozov updated DRILL-6288:
--
Description: 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]
  (was: 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])

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

2018-03-22 Thread ASF GitHub Bot (JIRA) 

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

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

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

https://github.com/apache/drill/pull/1160#discussion_r176593083
  
--- Diff: exec/java-exec/src/main/resources/rest/index.ftl ---
@@ -291,6 +300,46 @@
 var url = protocol + "//" + host + requestPath;
 return url;
   }
+
+  //Iterates through all the nodes for update
+  function reloadMemory () {
+  for (i = 1; i <= size; i++) {
+  var address = 
$("#row-"+i).find("#address").contents().get(0).nodeValue.trim();
+  updateMemory(address, i);
+  }
+  }
+
+  //Update memory
+  function updateMemory(drillbit,idx) {
+var result = $.ajax({
+  type: 'GET',
+  url: "http://"+drillbit+":8047/status/metrics;,
--- End diff --

So one way to find out a Drillbit's HTTP port is through this call:
`http://localhost:8047/portNum `
to get 
```
{
  "port" : 8047
}
```
Notice how I need to use the port number in the request's URL to get that 
very number! 藍 


> 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] [Created] (DRILL-6288) Upgrade org.javassist:javassist and org.reflections:reflections

2018-03-22 Thread Vlad Rozov (JIRA) 
Vlad Rozov created DRILL-6288:
-

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

2018-03-22 Thread ASF GitHub Bot (JIRA) 

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

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

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

https://github.com/apache/drill/pull/1160#discussion_r176592068
  
--- Diff: exec/java-exec/src/main/resources/rest/index.ftl ---
@@ -192,6 +199,8 @@
   var port = getPortNum();
   var timeout;
   var size = $("#size").html();
+  reloadMemory();
+  setInterval(reloadMemory, refreshTime);
--- End diff --

That's because the scheduler for graceful shutdown can change, while in 
this case we need a periodic refresh that shouldn't change.
As for a Drillbit going down, it can always come back online. As long as 
the page continues to list the Drillbit and it does get updated to reflect the 
status as "ONLINE" again, we should be pinging for the metrics too.


> 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] [Commented] (DRILL-6273) Remove dependency licensed under Category X

2018-03-22 Thread Vlad Rozov (JIRA) 

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

Vlad Rozov commented on DRILL-6273:
---

{noformat}
  - BeanShell (http://www.beanshell.org/) org.beanshell:bsh:jar:2.0b5
License: GNU LESSER GENERAL PUBLIC LICENSE  
(http://www.gnu.org/copyleft/lesser.html)
{noformat}

I use {{find . -name DEPENDENCIES -print | xargs grep -n License: | grep -vE 
"Apache|CDDL|MIT|BSD|ASF|PublicDomain|Eclipse Public License|Mozilla 
Public|Common Public|apache.org|WTFPL|Bouncy Castle|Public Domain"}} to find 
Category X licenses.



> 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
>Priority: Critical
> Fix For: 1.14.0
>
>




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

2018-03-22 Thread ASF GitHub Bot (JIRA) 

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

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

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

https://github.com/apache/drill/pull/1160#discussion_r176590360
  
--- Diff: exec/java-exec/src/main/resources/rest/index.ftl ---
@@ -291,6 +300,46 @@
 var url = protocol + "//" + host + requestPath;
 return url;
   }
+
+  //Iterates through all the nodes for update
+  function reloadMemory () {
+  for (i = 1; i <= size; i++) {
+  var address = 
$("#row-"+i).find("#address").contents().get(0).nodeValue.trim();
+  updateMemory(address, i);
+  }
+  }
+
+  //Update memory
+  function updateMemory(drillbit,idx) {
+var result = $.ajax({
+  type: 'GET',
+  url: "http://"+drillbit+":8047/status/metrics;,
--- End diff --

Actually, this is a challenge. We don't seem to be exposing any information 
on the http-port.  The only information I am getting back into DrillbitInfo are 
the other 3 ports: control, data and user. If I need to had HTTP to this (which 
I think it should), we need to modify the protobuf (UserBitShared). :(
Do you have any suggestions?


> 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] [Comment Edited] (DRILL-6286) Regression: incorrect reference to shutdown in drillbit.log

2018-03-22 Thread Venkata Jyothsna Donapati (JIRA) 

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

Venkata Jyothsna Donapati edited comment on DRILL-6286 at 3/22/18 10:24 PM:


This is duplicate of DRILL-6261 . It caused by changes made in DRILL-5922.

 


was (Author: vdonapati):
This is duplicate of 
[DRILL-6261|https://issues.apache.org/jira/browse/DRILL-6261] . It caused by 
changes made in DRILL-5292.

 

> 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] [Comment Edited] (DRILL-6286) Regression: incorrect reference to shutdown in drillbit.log

2018-03-22 Thread Venkata Jyothsna Donapati (JIRA) 

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

Venkata Jyothsna Donapati edited comment on DRILL-6286 at 3/22/18 10:23 PM:


This is duplicate of 
[DRILL-6261|https://issues.apache.org/jira/browse/DRILL-6261] . It caused by 
changes made in DRILL-5292.

 


was (Author: vdonapati):
This is duplicate of 
[[DRILL-6261|https://issues.apache.org/jira/browse/DRILL-6261]|https://issues.a/].
 It caused by changes made in DRILL-5292.

 

> 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] [Updated] (DRILL-6272) Remove binary jars files from source distribution

2018-03-22 Thread Pritesh Maker (JIRA) 

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

Pritesh Maker updated DRILL-6272:
-
Description: Per [~vrozov] the source distribution contains binary jar 
files under exec/java-exec/src/test/resources/jars

> 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
> 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] [Comment Edited] (DRILL-6286) Regression: incorrect reference to shutdown in drillbit.log

2018-03-22 Thread Venkata Jyothsna Donapati (JIRA) 

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

Venkata Jyothsna Donapati edited comment on DRILL-6286 at 3/22/18 10:22 PM:


This is duplicate of 
[[DRILL-6261|https://issues.apache.org/jira/browse/DRILL-6261]|https://issues.a/].
 It caused by changes made in DRILL-5292.

 


was (Author: vdonapati):
This is duplicate of https://issues.apache.org/jira/browse/DRILL-6261. It 
caused by changes made in 
[DRILL-5292|https://issues.apache.org/jira/browse/DRILL-5292].

 

> 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] [Assigned] (DRILL-6271) Update copyright range in NOTICE

2018-03-22 Thread Pritesh Maker (JIRA) 

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

Pritesh Maker reassigned DRILL-6271:


Assignee: Venkata Jyothsna Donapati

> 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

2018-03-22 Thread Venkata Jyothsna Donapati (JIRA) 

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

Venkata Jyothsna Donapati commented on DRILL-6286:
--

This is duplicate of https://issues.apache.org/jira/browse/DRILL-6261. It 
caused by changes made in 
[DRILL-5292|https://issues.apache.org/jira/browse/DRILL-5292].

 

> 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] [Assigned] (DRILL-6272) Remove binary jars files from source distribution

2018-03-22 Thread Pritesh Maker (JIRA) 

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

Pritesh Maker reassigned DRILL-6272:


Assignee: 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: Arina Ielchiieva
>Priority: Critical
> Fix For: 1.14.0
>
>




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

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

2018-03-22 Thread Pritesh Maker (JIRA) 

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

Pritesh Maker commented on DRILL-6273:
--

[~vrozov] can you provide more details on this issue? do you have a list of 
dependencies that are under Category X license 
(https://www.apache.org/legal/resolved.html)

> 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
>Priority: Critical
> Fix For: 1.14.0
>
>




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

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

2018-03-22 Thread Pritesh Maker (JIRA) 

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

Pritesh Maker reassigned DRILL-6286:


Assignee: Venkata Jyothsna Donapati  (was: Timothy Farkas)

> 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] [Updated] (DRILL-6286) Regression: incorrect reference to shutdown in drillbit.log

2018-03-22 Thread Pritesh Maker (JIRA) 

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

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

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

2018-03-22 Thread ASF GitHub Bot (JIRA) 

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

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

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

https://github.com/apache/drill/pull/1160#discussion_r176579901
  
--- Diff: exec/java-exec/src/main/resources/rest/index.ftl ---
@@ -291,6 +300,46 @@
 var url = protocol + "//" + host + requestPath;
 return url;
   }
+
+  //Iterates through all the nodes for update
+  function reloadMemory () {
+  for (i = 1; i <= size; i++) {
+  var address = 
$("#row-"+i).find("#address").contents().get(0).nodeValue.trim();
+  updateMemory(address, i);
+  }
+  }
+
+  //Update memory
+  function updateMemory(drillbit,idx) {
+var result = $.ajax({
+  type: 'GET',
+  url: "http://"+drillbit+":8047/status/metrics;,
--- End diff --

Good point. I'll follow the same port extraction logic.


> 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] [Commented] (DRILL-6224) The metrics' page has gauges reset to near zero values and does not seem to update

2018-03-22 Thread ASF GitHub Bot (JIRA) 

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

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

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

https://github.com/apache/drill/pull/1160#discussion_r176579720
  
--- Diff: exec/java-exec/src/main/resources/rest/index.ftl ---
@@ -53,11 +53,16 @@
 
   #
   Address
+  Heap Usage
+  Direct Usage
   User Port
   Control Port
   Data Port
   Version
   Status
+  <#if model.shouldShowAdminInfo() || !model.isAuthEnabled() >
--- End diff --

I need to rebase. DRILL-6044 fix changed that entry.


> 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] [Commented] (DRILL-5741) Automatically manage memory allocations during startup

2018-03-22 Thread Bridget Bevens (JIRA) 

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

Bridget Bevens commented on DRILL-5741:
---

Updated [https://drill.apache.org/docs/configuring-drill-memory/] to include 
the new parameter and behavior change.

Will remove doc-impacting. Please add the label back if the doc is not 
sufficient or needs to be edited.

Thanks,
Bridget

> Automatically manage memory allocations during startup
> --
>
> Key: DRILL-5741
> URL: https://issues.apache.org/jira/browse/DRILL-5741
> Project: Apache Drill
>  Issue Type: Improvement
>  Components:  Server
>Affects Versions: 1.11.0
>Reporter: Kunal Khatua
>Assignee: Kunal Khatua
>Priority: Major
>  Labels: ready-to-commit
> Fix For: 1.13.0
>
> Attachments: Auto Mem Allocation Proposal - Computation Logic.pdf, 
> Auto Mem Allocation Proposal - Scenarios.pdf
>
>
> Currently, during startup, a Drillbit can be assigned large values for the 
> following:
> * Xmx (Heap)
> * XX:MaxDirectMemorySize
> * XX:ReservedCodeCacheSize
> * XX:MaxPermSize
> All of this, potentially, can exceed the available memory on a system when a 
> Drillbit is under heavy load. It would be good to have the Drillbit ensure 
> during startup itself that the cumulative value of these parameters does not 
> exceed a pre-defined upper limit for the Drill process.
> This JIRA is a *proposal* to allow for automatic configuration (based on 
> configuration patterns observed in production Drill clusters). It leverages 
> the capability of providing default/distribution (and user-specific) checks 
> during Drill Startup from DRILL-6068.
> The idea is to remove the need for a user to worry about managing the tuning 
> parameters, by providing the optimal values. In addition, it also allows for 
> the memory allocation to be implicitly managed by simply providing the Drill 
> process with a single dimensional of total process memory (either in absolute 
> values, or as a percentage of the total system memory), while 
> {{auto-setup.sh}} provides the individual allocations.
> This allocation is then partitioned into allocations for Heap and Direct 
> Memory, with a small portion allocated for the Generated Java CodeCache as 
> well. If any of the individual allocations are also specified (via 
> {{distrib-env.sh}} or {{drill-env.sh}}), the remaining unspecified 
> allocations are adjusted to stay +within the limits+ of the total memory 
> allocation.
> The *details* of the proposal are here:
> https://docs.google.com/spreadsheets/d/1N6VYlQFiPoTV4iD46XbkIrvEQesiGFUU9-GWXYsAPXs/edit#gid=0
> For those unable to access the Google Document, PDFs are attached:
> * [^Auto Mem Allocation Proposal - Computation Logic.pdf] - Provides the 
> equation used for computing the heap, direct and code cache allocations for a 
> given input
> * [^Auto Mem Allocation Proposal - Scenarios.pdf] - Describes the various 
> inputs, and their expected allocations
> The variables that are (_optionally_) defined (in memory, {{distrib-env.sh}} 
> or {{drill-env.sh}} ) are:
> * {{DRILLBIT_MAX_PROC_MEM}} : Total Process Memory
> * {{DRILL_HEAP}} : JVM Max Heap Size
> * {{DRILL_MAX_DIRECT_MEMORY}} : JVM Max Direct Memory Size
> * {{DRILLBIT_CODE_CACHE_SIZE}} : JVM Code Cache Size
> Note: _With JDK8, MaxPermSize is no longer supported, so we do not account 
> for this any more, and will unset the variable if JDK8 or higher is detected._



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

[jira] [Updated] (DRILL-5741) Automatically manage memory allocations during startup

2018-03-22 Thread Bridget Bevens (JIRA) 

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

Bridget Bevens updated DRILL-5741:
--
Labels: ready-to-commit  (was: doc-impacting ready-to-commit)

> Automatically manage memory allocations during startup
> --
>
> Key: DRILL-5741
> URL: https://issues.apache.org/jira/browse/DRILL-5741
> Project: Apache Drill
>  Issue Type: Improvement
>  Components:  Server
>Affects Versions: 1.11.0
>Reporter: Kunal Khatua
>Assignee: Kunal Khatua
>Priority: Major
>  Labels: ready-to-commit
> Fix For: 1.13.0
>
> Attachments: Auto Mem Allocation Proposal - Computation Logic.pdf, 
> Auto Mem Allocation Proposal - Scenarios.pdf
>
>
> Currently, during startup, a Drillbit can be assigned large values for the 
> following:
> * Xmx (Heap)
> * XX:MaxDirectMemorySize
> * XX:ReservedCodeCacheSize
> * XX:MaxPermSize
> All of this, potentially, can exceed the available memory on a system when a 
> Drillbit is under heavy load. It would be good to have the Drillbit ensure 
> during startup itself that the cumulative value of these parameters does not 
> exceed a pre-defined upper limit for the Drill process.
> This JIRA is a *proposal* to allow for automatic configuration (based on 
> configuration patterns observed in production Drill clusters). It leverages 
> the capability of providing default/distribution (and user-specific) checks 
> during Drill Startup from DRILL-6068.
> The idea is to remove the need for a user to worry about managing the tuning 
> parameters, by providing the optimal values. In addition, it also allows for 
> the memory allocation to be implicitly managed by simply providing the Drill 
> process with a single dimensional of total process memory (either in absolute 
> values, or as a percentage of the total system memory), while 
> {{auto-setup.sh}} provides the individual allocations.
> This allocation is then partitioned into allocations for Heap and Direct 
> Memory, with a small portion allocated for the Generated Java CodeCache as 
> well. If any of the individual allocations are also specified (via 
> {{distrib-env.sh}} or {{drill-env.sh}}), the remaining unspecified 
> allocations are adjusted to stay +within the limits+ of the total memory 
> allocation.
> The *details* of the proposal are here:
> https://docs.google.com/spreadsheets/d/1N6VYlQFiPoTV4iD46XbkIrvEQesiGFUU9-GWXYsAPXs/edit#gid=0
> For those unable to access the Google Document, PDFs are attached:
> * [^Auto Mem Allocation Proposal - Computation Logic.pdf] - Provides the 
> equation used for computing the heap, direct and code cache allocations for a 
> given input
> * [^Auto Mem Allocation Proposal - Scenarios.pdf] - Describes the various 
> inputs, and their expected allocations
> The variables that are (_optionally_) defined (in memory, {{distrib-env.sh}} 
> or {{drill-env.sh}} ) are:
> * {{DRILLBIT_MAX_PROC_MEM}} : Total Process Memory
> * {{DRILL_HEAP}} : JVM Max Heap Size
> * {{DRILL_MAX_DIRECT_MEMORY}} : JVM Max Direct Memory Size
> * {{DRILLBIT_CODE_CACHE_SIZE}} : JVM Code Cache Size
> Note: _With JDK8, MaxPermSize is no longer supported, so we do not account 
> for this any more, and will unset the variable if JDK8 or higher is detected._



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

[jira] [Commented] (DRILL-6248) Support pushdown into System Table

2018-03-22 Thread ASF GitHub Bot (JIRA) 

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

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

GitHub user arina-ielchiieva opened a pull request:

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

DRILL-6248: Added limit push down support for system tables

1. PojoRecordReader started returning data in batches instead of returing 
all in one batch. Default batch size is 4000.
2. SystemTableScan supports limit push down while extrating data in record 
reader based on given max records to read.
3. Profiles and profiles_json tables apply limit push down while extracting 
data from store accessing profiles by range.

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

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

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

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

https://github.com/apache/drill/pull/1183.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 #1183


commit 1ae04bea3aa4a153572e230f0a456a4f4602e98c
Author: Arina Ielchiieva 
Date:   2018-03-20T18:26:42Z

DRILL-6248: Added limit push down support for system tables

1. PojoRecordReader started returning data in batches instead of returing 
all in one batch. Default batch size is 4000.
2. SystemTableScan supports limit push down while extrating data in record 
reader based on given max records to read.
3. Profiles and profiles_json tables apply limit push down while extracting 
data from store accessing profiles by range.




> Support pushdown into System Table
> --
>
> Key: DRILL-6248
> URL: https://issues.apache.org/jira/browse/DRILL-6248
> Project: Apache Drill
>  Issue Type: Improvement
>Affects Versions: 1.13.0
>Reporter: Kunal Khatua
>Assignee: Arina Ielchiieva
>Priority: Minor
> Fix For: 1.14.0
>
>
> When querying a profile store, we fetch all the records before applying a 
> limit.
> {code:sql}
> select * from sys.profiles limit 1
> {code}
> For a test scenario with 120K+ profiles in the store, a 
> {code:sql}
> select count(*) from sys.profiles
> {code}
> took 90 minutes.



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

[jira] [Commented] (DRILL-6248) Support pushdown into System Table

2018-03-22 Thread ASF GitHub Bot (JIRA) 

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

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

Github user arina-ielchiieva commented on the issue:

https://github.com/apache/drill/pull/1183
  
@kkhatua please review.


> Support pushdown into System Table
> --
>
> Key: DRILL-6248
> URL: https://issues.apache.org/jira/browse/DRILL-6248
> Project: Apache Drill
>  Issue Type: Improvement
>Affects Versions: 1.13.0
>Reporter: Kunal Khatua
>Assignee: Arina Ielchiieva
>Priority: Minor
> Fix For: 1.14.0
>
>
> When querying a profile store, we fetch all the records before applying a 
> limit.
> {code:sql}
> select * from sys.profiles limit 1
> {code}
> For a test scenario with 120K+ profiles in the store, a 
> {code:sql}
> select count(*) from sys.profiles
> {code}
> took 90 minutes.



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

[jira] [Closed] (DRILL-6199) Filter push down doesn't work with more than one nested subqueries

2018-03-22 Thread Anton Gozhiy (JIRA) 

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

Anton Gozhiy closed DRILL-6199.
---

Tested with Drill version 1.14.0-SNAPSHOT (commit id: 
b4c599e33606f3e2fef132dbd38ee69b516e681e)
Cases verified:
 - The original issue is not reproduced
 - Tried with queries with even more nested subqueries
 - Tested project pushdown and partition pruning with the same cases
 - Also used complicated queries with multiple levels, views, cte and subqueries

> Filter push down doesn't work with more than one nested subqueries
> --
>
> Key: DRILL-6199
> URL: https://issues.apache.org/jira/browse/DRILL-6199
> Project: Apache Drill
>  Issue Type: Bug
>Affects Versions: 1.13.0
>Reporter: Anton Gozhiy
>Assignee: Arina Ielchiieva
>Priority: Major
>  Labels: ready-to-commit
> Fix For: 1.14.0
>
> Attachments: DRILL_6118_data_source.csv
>
>
> *Data set:*
> The data is generated used the attached file: *DRILL_6118_data_source.csv*
> Data gen commands:
> {code:sql}
> create table dfs.tmp.`DRILL_6118_parquet_partitioned_by_folders/d1` (c1, c2, 
> c3, c4, c5) as select cast(columns[0] as int) c1, columns[1] c2, columns[2] 
> c3, columns[3] c4, columns[4] c5 from dfs.tmp.`DRILL_6118_data_source.csv` 
> where columns[0] in (1, 3);
> create table dfs.tmp.`DRILL_6118_parquet_partitioned_by_folders/d2` (c1, c2, 
> c3, c4, c5) as select cast(columns[0] as int) c1, columns[1] c2, columns[2] 
> c3, columns[3] c4, columns[4] c5 from dfs.tmp.`DRILL_6118_data_source.csv` 
> where columns[0]=2;
> create table dfs.tmp.`DRILL_6118_parquet_partitioned_by_folders/d3` (c1, c2, 
> c3, c4, c5) as select cast(columns[0] as int) c1, columns[1] c2, columns[2] 
> c3, columns[3] c4, columns[4] c5 from dfs.tmp.`DRILL_6118_data_source.csv` 
> where columns[0]>3;
> {code}
> *Steps:*
> # Execute the following query:
> {code:sql}
> explain plan for select * from (select * from (select * from 
> dfs.tmp.`DRILL_6118_parquet_partitioned_by_folders`)) where c1<3
> {code}
> *Expected result:*
> numFiles=2, numRowGroups=2, only files from the folders d1 and d2 should be 
> scanned.
> *Actual result:*
> Filter push down doesn't work:
> numFiles=3, numRowGroups=3, scanning from all files



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

[jira] [Updated] (DRILL-6248) Support pushdown into System Table

2018-03-22 Thread Arina Ielchiieva (JIRA) 

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

Arina Ielchiieva updated DRILL-6248:

Reviewer: Kunal Khatua

> Support pushdown into System Table
> --
>
> Key: DRILL-6248
> URL: https://issues.apache.org/jira/browse/DRILL-6248
> Project: Apache Drill
>  Issue Type: Improvement
>Affects Versions: 1.13.0
>Reporter: Kunal Khatua
>Assignee: Arina Ielchiieva
>Priority: Minor
> Fix For: 1.14.0
>
>
> When querying a profile store, we fetch all the records before applying a 
> limit.
> {code:sql}
> select * from sys.profiles limit 1
> {code}
> For a test scenario with 120K+ profiles in the store, a 
> {code:sql}
> select count(*) from sys.profiles
> {code}
> took 90 minutes.



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

[jira] [Commented] (DRILL-6248) Support pushdown into System Table

2018-03-22 Thread Arina Ielchiieva (JIRA) 

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

Arina Ielchiieva commented on DRILL-6248:
-

Currently limit push down is not applied to any system tables. Generally there 
are fairly small and thus such optimizations is not critical.
In case of profiles tables it can be fairly large. Design of system tables are 
done in such way that data is all loaded into memory (this can be a subject for 
further optimizations, not tackling this issue here, since it may required 
re-design of system tables handling plus since primary profiles table is used 
for testing purposes, I do not think such optimization is highly critical).

Adding limit push down support can be done but selecting profiles in ranges, 
this will definitely improve performance if limit is low.
Also while adding push down support I have noticed that pojo record reader does 
not leverage batches, so such support should be added as well.

Regarding second issue with count, rule ConvertCountToDirectScan is responsible 
for such optimizations. During planning we don't know exact number of profiles 
to fetch plus we'll need to fetch all data anyway (especially from ZK) before 
we can receive exact count, so there will no significant performance 
improvement. 
Actually I had 80K+ profiles on my cluster and it took several minutes to 
return their count. It definitely can take longer if ZK is overloaded (for 
example, many queries are submitted / executed at that time). Anyway, ZK is not 
designed to store such information and we won't be able to get high performance 
while querying it. In future when proper metastore will be implemented based on 
some DB, it will definitely resolve performance issues.

> Support pushdown into System Table
> --
>
> Key: DRILL-6248
> URL: https://issues.apache.org/jira/browse/DRILL-6248
> Project: Apache Drill
>  Issue Type: Improvement
>Affects Versions: 1.13.0
>Reporter: Kunal Khatua
>Assignee: Arina Ielchiieva
>Priority: Minor
> Fix For: 1.14.0
>
>
> When querying a profile store, we fetch all the records before applying a 
> limit.
> {code:sql}
> select * from sys.profiles limit 1
> {code}
> For a test scenario with 120K+ profiles in the store, a 
> {code:sql}
> select count(*) from sys.profiles
> {code}
> took 90 minutes.



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

[jira] [Updated] (DRILL-6287) apache-release profile should be disabled by default

2018-03-22 Thread Vlad Rozov (JIRA) 

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

Vlad Rozov updated DRILL-6287:
--
Reviewer: Parth Chandra

> apache-release profile should be disabled by default
> 
>
> Key: DRILL-6287
> URL: https://issues.apache.org/jira/browse/DRILL-6287
> Project: Apache Drill
>  Issue Type: Bug
>Reporter: Vlad Rozov
>Assignee: Vlad Rozov
>Priority: Minor
>




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

[jira] [Commented] (DRILL-6287) apache-release profile should be disabled by default

2018-03-22 Thread ASF GitHub Bot (JIRA) 

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

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

GitHub user vrozov opened a pull request:

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

DRILL-6287: apache-release profile should be disabled by default

@parthchandra @dvjyothsna Please review

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

$ git pull https://github.com/vrozov/drill DRILL-6287

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

https://github.com/apache/drill/pull/1182.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 #1182


commit 23745ab83305373f5d8040ed65070d82b5ea4aa7
Author: Vlad Rozov 
Date:   2018-03-22T13:54:56Z

DRILL-6287: apache-release profile should be disabled by default




> apache-release profile should be disabled by default
> 
>
> Key: DRILL-6287
> URL: https://issues.apache.org/jira/browse/DRILL-6287
> Project: Apache Drill
>  Issue Type: Bug
>Reporter: Vlad Rozov
>Assignee: Vlad Rozov
>Priority: Minor
>




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

[jira] [Created] (DRILL-6287) apache-release profile should be disabled by default

2018-03-22 Thread Vlad Rozov (JIRA) 
Vlad Rozov created DRILL-6287:
-

 Summary: apache-release profile should be disabled by default
 Key: DRILL-6287
 URL: https://issues.apache.org/jira/browse/DRILL-6287
 Project: Apache Drill
  Issue Type: Bug
Reporter: Vlad Rozov
Assignee: Vlad Rozov






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

[jira] [Closed] (DRILL-6250) Sqlline start command with password appears in the sqlline.log

2018-03-22 Thread Anton Gozhiy (JIRA) 

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

Anton Gozhiy closed DRILL-6250.
---

Verified with Drill version 1.14.0-SNAPSHOT (commit id: 
b4c599e33606f3e2fef132dbd38ee69b516e681e)
Checked:
 - sqlline.log
 - drillbit.log
 - drillbit.out
No sqlline start command or passwords appeared in the logs.

> Sqlline start command with password appears in the sqlline.log
> --
>
> Key: DRILL-6250
> URL: https://issues.apache.org/jira/browse/DRILL-6250
> Project: Apache Drill
>  Issue Type: Bug
>Affects Versions: 1.13.0
>Reporter: Anton Gozhiy
>Assignee: Volodymyr Tkach
>Priority: Major
>  Labels: ready-to-commit
> Fix For: 1.14.0
>
>
> *Prerequisites:*
>  *1.* Log level is set to "all" in the conf/logback.xml:
> {code:xml}
> 
> 
> 
> 
> {code}
> *2.* PLAIN authentication mechanism is configured:
> {code:java}
>   security.user.auth: {
>   enabled: true,
>   packages += "org.apache.drill.exec.rpc.user.security",
>   impl: "pam",
>   pam_profiles: [ "sudo", "login" ]
>   }
> {code}
> *Steps:*
>  *1.* Start the drillbits
>  *2.* Connect by sqlline:
> {noformat}
> /opt/mapr/drill/drill-1.13.0/bin/sqlline -u "jdbc:drill:zk=node1:5181;" -n 
> user1 -p 1234
> {noformat}
> *3.* Use check the sqlline logs:
> {noformat}
> tail -F log/sqlline.log|grep 1234 -a5 -b5
> {noformat}
> *Expected result:* Logs shouldn't contain clear-text passwords
> *Actual result:* The logs contain the sqlline start command with password:
> {noformat}
> # system properties
> 35333-"java" : {
> 35352-# system properties
> 35384:"command" : "sqlline.SqlLine -d 
> org.apache.drill.jdbc.Driver --maxWidth=1 --color=true -u 
> jdbc:drill:zk=node1:5181; -n user1 -p 1234",
> 35535-# system properties
> 35567-"launcher" : "SUN_STANDARD"
> 35607-}
> {noformat}



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

[jira] [Updated] (DRILL-6283) WebServer stores SPNEGO client principal without taking any conversion rule

2018-03-22 Thread Arina Ielchiieva (JIRA) 

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

Arina Ielchiieva updated DRILL-6283:

Labels: ready-to-commit  (was: )

> WebServer stores SPNEGO client principal without taking any conversion rule
> ---
>
> Key: DRILL-6283
> URL: https://issues.apache.org/jira/browse/DRILL-6283
> Project: Apache Drill
>  Issue Type: Bug
>  Components: Web Server
>Affects Versions: 1.13.0
>Reporter: Sorabh Hamirwasia
>Assignee: Sorabh Hamirwasia
>Priority: Major
>  Labels: ready-to-commit
> Fix For: 1.14.0
>
>
> Drill's WebServer uses the exact client principal (us...@qa.lab) as the 
> stored username, it doesn't provide any configuration to specify rules which 
> can be used to extract desired username from client's principal.
> For example: default rule provided by HadoopKerberosName extracts only the 
> primary part (user1) in client principal. 
> Also while checking if authenticated client principal has admin privileges or 
> not it uses realm (e.g. QA.LAB) information to verify against configured 
> admin user/group list. To make it consistent with JDBC/ODBC kerberos path, it 
> should use the shortName in client principal to determine admin privileges.
> Basically server side should store the shortName from client principal 
> extracted based on configured rule and use that to determine the admin 
> privileges too.



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

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

2018-03-22 Thread Arina Ielchiieva (JIRA) 

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

Arina Ielchiieva updated DRILL-6282:

Issue Type: Bug  (was: Improvement)

> 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-6283) WebServer stores SPNEGO client principal without taking any conversion rule

2018-03-22 Thread ASF GitHub Bot (JIRA) 

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

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

Github user arina-ielchiieva commented on the issue:

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


> WebServer stores SPNEGO client principal without taking any conversion rule
> ---
>
> Key: DRILL-6283
> URL: https://issues.apache.org/jira/browse/DRILL-6283
> Project: Apache Drill
>  Issue Type: Bug
>  Components: Web Server
>Affects Versions: 1.13.0
>Reporter: Sorabh Hamirwasia
>Assignee: Sorabh Hamirwasia
>Priority: Major
>  Labels: ready-to-commit
> Fix For: 1.14.0
>
>
> Drill's WebServer uses the exact client principal (us...@qa.lab) as the 
> stored username, it doesn't provide any configuration to specify rules which 
> can be used to extract desired username from client's principal.
> For example: default rule provided by HadoopKerberosName extracts only the 
> primary part (user1) in client principal. 
> Also while checking if authenticated client principal has admin privileges or 
> not it uses realm (e.g. QA.LAB) information to verify against configured 
> admin user/group list. To make it consistent with JDBC/ODBC kerberos path, it 
> should use the shortName in client principal to determine admin privileges.
> Basically server side should store the shortName from client principal 
> extracted based on configured rule and use that to determine the admin 
> privileges too.



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

[jira] [Commented] (DRILL-6237) Upgrade checkstyle version to 5.9 or above

2018-03-22 Thread Arina Ielchiieva (JIRA) 

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

Arina Ielchiieva commented on DRILL-6237:
-

Chnages are in the PR with DRILL-6053: 
https://github.com/apache/drill/pull/1163.

> Upgrade checkstyle version to 5.9 or above
> --
>
> Key: DRILL-6237
> URL: https://issues.apache.org/jira/browse/DRILL-6237
> Project: Apache Drill
>  Issue Type: Task
>Reporter: Vlad Rozov
>Assignee: Vlad Rozov
>Priority: Minor
>  Labels: ready-to-commit
> Fix For: 1.14.0
>
>
> Checkstyle versions prior to 5.9 do not support Java 8 syntax.



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

[jira] [Updated] (DRILL-6237) Upgrade checkstyle version to 5.9 or above

2018-03-22 Thread Arina Ielchiieva (JIRA) 

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

Arina Ielchiieva updated DRILL-6237:

Labels: ready-to-commit  (was: )

> Upgrade checkstyle version to 5.9 or above
> --
>
> Key: DRILL-6237
> URL: https://issues.apache.org/jira/browse/DRILL-6237
> Project: Apache Drill
>  Issue Type: Task
>Reporter: Vlad Rozov
>Assignee: Vlad Rozov
>Priority: Minor
>  Labels: ready-to-commit
> Fix For: 1.14.0
>
>
> Checkstyle versions prior to 5.9 do not support Java 8 syntax.



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

[jira] [Updated] (DRILL-6053) Avoid excessive locking in LocalPersistentStore

2018-03-22 Thread Arina Ielchiieva (JIRA) 

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

Arina Ielchiieva updated DRILL-6053:

Labels: ready-to-commit  (was: )

> Avoid excessive locking in LocalPersistentStore
> ---
>
> Key: DRILL-6053
> URL: https://issues.apache.org/jira/browse/DRILL-6053
> Project: Apache Drill
>  Issue Type: Improvement
>Reporter: Vlad Rozov
>Assignee: Vlad Rozov
>Priority: Major
>  Labels: ready-to-commit
> Fix For: 1.14.0
>
>
> When query profiles are written to LocalPersistentStore, the write is 
> unnecessary serialized due to read/write lock that was introduced for 
> versioned PersistentStore. Only versioned access needs to be protected by 
> read/write lock.



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

[jira] [Updated] (DRILL-6237) Upgrade checkstyle version to 5.9 or above

2018-03-22 Thread Arina Ielchiieva (JIRA) 

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

Arina Ielchiieva updated DRILL-6237:

Fix Version/s: 1.14.0

> Upgrade checkstyle version to 5.9 or above
> --
>
> Key: DRILL-6237
> URL: https://issues.apache.org/jira/browse/DRILL-6237
> Project: Apache Drill
>  Issue Type: Task
>Reporter: Vlad Rozov
>Assignee: Vlad Rozov
>Priority: Minor
>  Labels: ready-to-commit
> Fix For: 1.14.0
>
>
> Checkstyle versions prior to 5.9 do not support Java 8 syntax.



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

[jira] [Commented] (DRILL-6053) Avoid excessive locking in LocalPersistentStore

2018-03-22 Thread ASF GitHub Bot (JIRA) 

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

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

Github user arina-ielchiieva commented on the issue:

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


> Avoid excessive locking in LocalPersistentStore
> ---
>
> Key: DRILL-6053
> URL: https://issues.apache.org/jira/browse/DRILL-6053
> Project: Apache Drill
>  Issue Type: Improvement
>Reporter: Vlad Rozov
>Assignee: Vlad Rozov
>Priority: Major
> Fix For: 1.14.0
>
>
> When query profiles are written to LocalPersistentStore, the write is 
> unnecessary serialized due to read/write lock that was introduced for 
> versioned PersistentStore. Only versioned access needs to be protected by 
> read/write lock.



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