[jira] [Assigned] (DRILL-6183) Default value for parameter 'planner.width.max_per_node'

[Kunal Khatua (JIRA)]

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

Kunal Khatua reassigned DRILL-6183:
---

Assignee: (was: Kunal Khatua)

> Default value for parameter 'planner.width.max_per_node'
> 
>
> Key: DRILL-6183
> URL: https://issues.apache.org/jira/browse/DRILL-6183
> Project: Apache Drill
>  Issue Type: Bug
>  Components:  Server
>Affects Versions: 1.12.0
> Environment: Drill 1.12
>Reporter: Arjun
>Priority: Minor
>
> The default value for configuration parameter 'planner.width.max_per_node' is 
> shown as 0 in Drill 1.12. In the previous versions, the default value is set 
> as 70% total core in the drillbit node.This could be confusing for users 
> upgrading from previous versions ( Whether it is unlimited value).  
> {code:java}
> 0: jdbc:drill:drillbit=localhost> select * from sys.options where name like 
> '%planner.width%'; 
> +--+---+---+--+--+--+-+---++
> | name | kind | accessibleScopes | optionScope | status | num_val | 
> string_val | bool_val | float_val |
> +--+---+---+--+--+--+-+---++
> | planner.width.max_per_node | LONG | ALL | BOOT | DEFAULT | 0 | null | null 
> | null |
> | planner.width.max_per_query | LONG | ALL | BOOT | DEFAULT | 1000 | null | 
> null | null |
> +--+---+---+--+--+--+-+---++
> 2 rows selected (0.913 seconds) 0: jdbc:drill:drillbit=localhost>
> {code}



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

[jira] [Commented] (DRILL-6125) PartitionSenderRootExec can leak memory because close method is not synchronized

[ASF GitHub Bot (JIRA)]

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

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

Github user ilooner commented on the issue:

https://github.com/apache/drill/pull/1105
  
@vrozov @arina-ielchiieva Handled multiple receiver finished messages 
correctly. This PR is ready for another round of review.


> PartitionSenderRootExec can leak memory because close method is not 
> synchronized
> 
>
> Key: DRILL-6125
> URL: https://issues.apache.org/jira/browse/DRILL-6125
> Project: Apache Drill
>  Issue Type: Bug
>Affects Versions: 1.13.0
>Reporter: Timothy Farkas
>Assignee: Timothy Farkas
>Priority: Minor
> Fix For: 1.14.0
>
>
> PartitionSenderRootExec creates a PartitionerDecorator and saves it in the 
> *partitioner* field. The creation of the partitioner happens in the 
> createPartitioner method. This method get's called by the main fragment 
> thread. The partitioner field is accessed by the fragment thread during 
> normal execution but it can also be accessed by the receivingFragmentFinished 
> method which is a callback executed by the event processor thread. Because 
> multiple threads can access the partitioner field synchronization is done on 
> creation and on when receivingFragmentFinished. However, the close method can 
> also be called by the event processor thread, and the close method does not 
> synchronize before accessing the partitioner field. Since synchronization is 
> not done the event processor thread may have an old reference to the 
> partitioner when a query cancellation is done. Since it has an old reference 
> the current partitioner can may not be cleared and a memory leak may occur.



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

[jira] [Commented] (DRILL-6151) Fragment executors may terminate without sending final batch to a downstream causing query to hang

[ASF GitHub Bot (JIRA)]

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

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

Github user asfgit closed the pull request at:

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


> Fragment executors may terminate without sending final batch to a downstream 
> causing query to hang
> --
>
> Key: DRILL-6151
> URL: https://issues.apache.org/jira/browse/DRILL-6151
> Project: Apache Drill
>  Issue Type: Bug
>Affects Versions: 1.12.0
>Reporter: Vlad Rozov
>Assignee: Vlad Rozov
>Priority: Major
>  Labels: ready-to-commit
> Fix For: 1.13.0
>
>




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

[jira] [Commented] (DRILL-6040) Need to add usage for graceful_stop to drillbit.sh

[ASF GitHub Bot (JIRA)]

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

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

Github user asfgit closed the pull request at:

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


> Need to add usage for graceful_stop to drillbit.sh
> --
>
> Key: DRILL-6040
> URL: https://issues.apache.org/jira/browse/DRILL-6040
> Project: Apache Drill
>  Issue Type: Bug
>  Components: Execution - Flow
>Affects Versions: 1.13.0
>Reporter: Krystal
>Assignee: Venkata Jyothsna Donapati
>Priority: Major
>  Labels: ready-to-commit
> Fix For: 1.13.0
>
>
> git.commit.id.abbrev=eb0c403
> Usage for graceful_stop is missing from drillbit.sh.
> ./drillbit.sh
> Usage: drillbit.sh [--config|--site ] 
> (start|stop|status|restart|run) [args]



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

[jira] [Commented] (DRILL-6021) Show shutdown button when authentication is not enabled

[ASF GitHub Bot (JIRA)]

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

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

Github user asfgit closed the pull request at:

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


> Show shutdown button when authentication is not enabled
> ---
>
> Key: DRILL-6021
> URL: https://issues.apache.org/jira/browse/DRILL-6021
> Project: Apache Drill
>  Issue Type: Bug
>Affects Versions: 1.12.0
>Reporter: Arina Ielchiieva
>Assignee: Venkata Jyothsna Donapati
>Priority: Major
>  Labels: ready-to-commit
> Fix For: 1.13.0
>
>
> After DRILL-6017 {{shouldShowAdminInfo}} is used to decide if shutdown button 
> should be displayed on index page. But this option is set to true when 
> authentication is enabled and user is an admin. When authentication is not 
> enabled, user by default is admin. So with this fix without authentication, 
> shutdown button is absent but should be present.



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

[jira] [Commented] (DRILL-6126) Allocate memory for value vectors upfront in flatten operator

[ASF GitHub Bot (JIRA)]

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

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

Github user asfgit closed the pull request at:

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


> Allocate memory for value vectors upfront in flatten operator
> -
>
> Key: DRILL-6126
> URL: https://issues.apache.org/jira/browse/DRILL-6126
> Project: Apache Drill
>  Issue Type: Improvement
>Reporter: Padma Penumarthy
>Assignee: Padma Penumarthy
>Priority: Critical
>  Labels: ready-to-commit
> Fix For: 1.13.0
>
>
> With recent changes to control batch size for flatten operator, we figure out 
> row count in the output batch based on memory. Since we know how many rows we 
> are going to include in the batch, we can also allocate the memory needed 
> upfront instead of starting with initial value (4096) and doubling, copying 
> every time we need more. 



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

[jira] [Commented] (DRILL-4120) dir0 does not work when the directory structure contains Avro files

[ASF GitHub Bot (JIRA)]

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

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

Github user asfgit closed the pull request at:

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


> dir0 does not work when the directory structure contains Avro files
> ---
>
> Key: DRILL-4120
> URL: https://issues.apache.org/jira/browse/DRILL-4120
> Project: Apache Drill
>  Issue Type: Bug
>  Components: Query Planning  Optimization, Storage - Avro
>Affects Versions: 1.3.0
>Reporter: Stefán Baxter
>Assignee: Volodymyr Vysotskyi
>Priority: Major
>  Labels: ready-to-commit
> Fix For: 1.13.0
>
> Attachments: 
> 0001-DRILL-4120-Support-reading-directories-having-avro-f.patch
>
>
> Any select statment containing dirN fails if the target directory structure 
> contains Avro files.
> Steps to test:
> 1. create a simple directory structure
> 2. copy an avro file into each directory
> 3. execute a query containing dir0
> outcome:
> Error: VALIDATION ERROR: From line 1, column 117 to line 1, column 120: 
> Column 'dir0' not found in any table



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

[jira] [Comment Edited] (DRILL-6183) Default value for parameter 'planner.width.max_per_node'

[Kunal Khatua (JIRA)]

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

Kunal Khatua edited comment on DRILL-6183 at 3/8/18 2:31 AM:
-

[~arjun_kr], there was a change introduced in 1.12 (DRILL-5547) that takes into 
account CPU load factor, which is the 70% you are referring to.
https://github.com/apache/drill/blame/master/exec/java-exec/src/main/java/org/apache/drill/exec/server/options/TypeValidators.java#L262

The reason for this is that Zero is indicative of the maxWidth being done 
during planning time and need not be specified upfront. The original code would 
use the hard-coded 70%. 

A possible workaround could be to have the default pre-computed from the 
provided default cpu_load_factor so that you know what the default would be, 
but I am not sure if we need that.


was (Author: kkhatua):
[~arjun_kr], there was a change introduced in 1.12 (DRILL-5547) that takes into 
account CPU load factor, which is the 70% you are referring to.
https://github.com/apache/drill/blame/master/exec/java-exec/src/main/java/org/apache/drill/exec/server/options/TypeValidators.java#L262

The reason for this is that Zero is indicative of the maxWidth being done 
during planning time and need not be specified upfront. The original code would 
use the hard-coded 70%. 

A possible workaround could be to have the default pre-computed from the 
provided default cpu_load_factor so that you know what the default would be.

> Default value for parameter 'planner.width.max_per_node'
> 
>
> Key: DRILL-6183
> URL: https://issues.apache.org/jira/browse/DRILL-6183
> Project: Apache Drill
>  Issue Type: Bug
>  Components:  Server
>Affects Versions: 1.12.0
> Environment: Drill 1.12
>Reporter: Arjun
>Assignee: Kunal Khatua
>Priority: Minor
>
> The default value for configuration parameter 'planner.width.max_per_node' is 
> shown as 0 in Drill 1.12. In the previous versions, the default value is set 
> as 70% total core in the drillbit node.This could be confusing for users 
> upgrading from previous versions ( Whether it is unlimited value).  
> {code:java}
> 0: jdbc:drill:drillbit=localhost> select * from sys.options where name like 
> '%planner.width%'; 
> +--+---+---+--+--+--+-+---++
> | name | kind | accessibleScopes | optionScope | status | num_val | 
> string_val | bool_val | float_val |
> +--+---+---+--+--+--+-+---++
> | planner.width.max_per_node | LONG | ALL | BOOT | DEFAULT | 0 | null | null 
> | null |
> | planner.width.max_per_query | LONG | ALL | BOOT | DEFAULT | 1000 | null | 
> null | null |
> +--+---+---+--+--+--+-+---++
> 2 rows selected (0.913 seconds) 0: jdbc:drill:drillbit=localhost>
> {code}



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

[jira] [Commented] (DRILL-6183) Default value for parameter 'planner.width.max_per_node'

[Kunal Khatua (JIRA)]

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

Kunal Khatua commented on DRILL-6183:
-

[~arjun_kr], there was a change introduced in 1.12 (DRILL-5547) that takes into 
account CPU load factor, which is the 70% you are referring to.
https://github.com/apache/drill/blame/master/exec/java-exec/src/main/java/org/apache/drill/exec/server/options/TypeValidators.java#L262

The reason for this is that Zero is indicative of the maxWidth being done 
during planning time and need not be specified upfront. The original code would 
use the hard-coded 70%. 

A possible workaround could be to have the default pre-computed from the 
provided default cpu_load_factor so that you know what the default would be.

> Default value for parameter 'planner.width.max_per_node'
> 
>
> Key: DRILL-6183
> URL: https://issues.apache.org/jira/browse/DRILL-6183
> Project: Apache Drill
>  Issue Type: Bug
>  Components:  Server
>Affects Versions: 1.12.0
> Environment: Drill 1.12
>Reporter: Arjun
>Assignee: Kunal Khatua
>Priority: Minor
>
> The default value for configuration parameter 'planner.width.max_per_node' is 
> shown as 0 in Drill 1.12. In the previous versions, the default value is set 
> as 70% total core in the drillbit node.This could be confusing for users 
> upgrading from previous versions ( Whether it is unlimited value).  
> {code:java}
> 0: jdbc:drill:drillbit=localhost> select * from sys.options where name like 
> '%planner.width%'; 
> +--+---+---+--+--+--+-+---++
> | name | kind | accessibleScopes | optionScope | status | num_val | 
> string_val | bool_val | float_val |
> +--+---+---+--+--+--+-+---++
> | planner.width.max_per_node | LONG | ALL | BOOT | DEFAULT | 0 | null | null 
> | null |
> | planner.width.max_per_query | LONG | ALL | BOOT | DEFAULT | 1000 | null | 
> null | null |
> +--+---+---+--+--+--+-+---++
> 2 rows selected (0.913 seconds) 0: jdbc:drill:drillbit=localhost>
> {code}



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

[jira] [Commented] (DRILL-6187) Exception in RPC communication between DataClient/ControlClient and respective servers when bit-to-bit security is on

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/drill/pull/1145#discussion_r173041288
  
--- Diff: exec/rpc/src/main/java/org/apache/drill/exec/rpc/BasicClient.java 
---
@@ -182,6 +196,66 @@ public boolean isActive() {
 
   protected abstract void validateHandshake(HR validateHandshake) throws 
RpcException;
 
+  /**
+   * Creates various instances needed to start the SASL handshake. This is 
called from
+   * {@link BasicClient#validateHandshake(MessageLite)} if authentication 
is required from server side.
+   * @param connectionListener
+   * @throws RpcException
+   */
+  protected abstract void prepareSaslHandshake(final 
RpcConnectionHandler connectionListener) throws RpcException;
--- End diff --

removed from here and `startSaslHandshake`


> Exception in RPC communication between DataClient/ControlClient and 
> respective servers when bit-to-bit security is on
> -
>
> Key: DRILL-6187
> URL: https://issues.apache.org/jira/browse/DRILL-6187
> Project: Apache Drill
>  Issue Type: Bug
>  Components: Execution - RPC, Security
>Reporter: Sorabh Hamirwasia
>Assignee: Sorabh Hamirwasia
>Priority: Major
> Fix For: 1.13.0
>
>
>  
> {color:#00}Below is the summary of issue: {color}
>  
> {color:#00}*Scenario:*{color}
> {color:#00}It seems like first sendRecordBatch was sent to Foreman which 
> initiated the Authentication handshake. But before initiating handshake for 
> auth we establish a connection and store that in a registry. Now if in 
> parallel there is another recordBatch (by a different minor fragment running 
> on same Drillbit) to be sent then that will see the connection available in 
> registry and will initiate the send. Before the authentication is completed 
> this second request reached foreman and it throws below exception saying RPC 
> type 3 message is not allowed and closes the connection. This also fails the 
> authentication handshake which was in progress.{color}{color:#00} Here 
> the logs with details:{color}
> {color:#00} {color}
> {color:#00}*Forman received the SASL_START message from another 
> node:*{color}
> {color:#00}*_2018-02-21 18:43:30,759 
> [_*{color}{color:#00}_BitServer-4] TRACE 
> o.a.d.e.r.s.ServerAuthenticationHandler - Received SASL message SASL_START 
> from /10.10.100.161:35482_{color}
> {color:#00} {color}
> {color:#00}*Then around same time it received another message from client 
> of Rpc Type 3 which is for SendRecordBatch and fails since handshake is not 
> completed yet.*{color}
> {color:#00} {color}
> {color:#00}*_2018-02-21 18:43:30,762_*{color}{color:#00} 
> _[BitServer-4] ERROR o.a.d.exec.rpc.RpcExceptionHandler - Exception in RPC 
> communication.  Connection: /10.10.100.162:31012 <--> /__10.10.100.161:35482_ 
> _(data server).  Closing connection._{color}
> {color:#00}_io.netty.handler.codec.DecoderException: 
> org.apache.drill.exec.rpc.RpcException: Request of type 3 is not allowed 
> without authentication. Client on /__10.10.100.161:35482_ _must authenticate 
> before making requests. Connection dropped. [Details: Encryption: enabled , 
> MaxWrappedSize: 65536 , WrapSizeLimit: 0]_{color}
> {color:#00} {color}
> {color:#00}*Then client receives an channel closed exception:*{color}
> {color:#00} {color}
> {color:#00}*2018-02-21 18:43:30,764 [*{color}{color:#00}BitClient-4] 
> WARN  o.a.d.exec.rpc.RpcExceptionHandler - Exception occurred with closed 
> channel.  Connection: /_10.10.100.161:35482_ <--> _10.10.100.162:31012_ (data 
> client){color}
> {color:#00} {color}
> {color:#00}*and due to this it's initial command for authentication also 
> fails. Since there is channel closed exception above I will think that 
> triggered the failure of authentication request as well.*{color}
> {color:#00} {color}
> {color:#00}_Caused by: org.apache.drill.exec.rpc.RpcException: Command 
> failed while establishing connection.  Failure type AUTHENTICATION._{color}
> {color:#00}        _at 
> org.apache.drill.exec.rpc.RpcException.mapException(RpcException.java:67) 
> ~[drill-rpc-1.12.0-mapr.jar:1.12.0-mapr]_{color}
> {color:#00}        _at 
> org.apache.drill.exec.rpc.ListeningCommand.connectionFailed(ListeningCommand.java:66)
>  ~[drill-rpc-1.12.0-mapr.jar:1.12.0-mapr]_{color}
> {color:#00}        _at 
> 

[jira] [Commented] (DRILL-6187) Exception in RPC communication between DataClient/ControlClient and respective servers when bit-to-bit security is on

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/drill/pull/1145#discussion_r173041420
  
--- Diff: exec/rpc/src/main/java/org/apache/drill/exec/rpc/BasicClient.java 
---
@@ -69,6 +74,11 @@
   private final IdlePingHandler pingHandler;
   private ConnectionMultiListener.SSLHandshakeListener 
sslHandshakeListener = null;
 
+  // Authentication related parameters
+  protected volatile List serverAuthMechanisms = null;
--- End diff --

On second thought volatile doesn't seem necessary here since it will only 
be accessed by Netty's thread which is also fixed for a connection. 
Made fields private.


> Exception in RPC communication between DataClient/ControlClient and 
> respective servers when bit-to-bit security is on
> -
>
> Key: DRILL-6187
> URL: https://issues.apache.org/jira/browse/DRILL-6187
> Project: Apache Drill
>  Issue Type: Bug
>  Components: Execution - RPC, Security
>Reporter: Sorabh Hamirwasia
>Assignee: Sorabh Hamirwasia
>Priority: Major
> Fix For: 1.13.0
>
>
>  
> {color:#00}Below is the summary of issue: {color}
>  
> {color:#00}*Scenario:*{color}
> {color:#00}It seems like first sendRecordBatch was sent to Foreman which 
> initiated the Authentication handshake. But before initiating handshake for 
> auth we establish a connection and store that in a registry. Now if in 
> parallel there is another recordBatch (by a different minor fragment running 
> on same Drillbit) to be sent then that will see the connection available in 
> registry and will initiate the send. Before the authentication is completed 
> this second request reached foreman and it throws below exception saying RPC 
> type 3 message is not allowed and closes the connection. This also fails the 
> authentication handshake which was in progress.{color}{color:#00} Here 
> the logs with details:{color}
> {color:#00} {color}
> {color:#00}*Forman received the SASL_START message from another 
> node:*{color}
> {color:#00}*_2018-02-21 18:43:30,759 
> [_*{color}{color:#00}_BitServer-4] TRACE 
> o.a.d.e.r.s.ServerAuthenticationHandler - Received SASL message SASL_START 
> from /10.10.100.161:35482_{color}
> {color:#00} {color}
> {color:#00}*Then around same time it received another message from client 
> of Rpc Type 3 which is for SendRecordBatch and fails since handshake is not 
> completed yet.*{color}
> {color:#00} {color}
> {color:#00}*_2018-02-21 18:43:30,762_*{color}{color:#00} 
> _[BitServer-4] ERROR o.a.d.exec.rpc.RpcExceptionHandler - Exception in RPC 
> communication.  Connection: /10.10.100.162:31012 <--> /__10.10.100.161:35482_ 
> _(data server).  Closing connection._{color}
> {color:#00}_io.netty.handler.codec.DecoderException: 
> org.apache.drill.exec.rpc.RpcException: Request of type 3 is not allowed 
> without authentication. Client on /__10.10.100.161:35482_ _must authenticate 
> before making requests. Connection dropped. [Details: Encryption: enabled , 
> MaxWrappedSize: 65536 , WrapSizeLimit: 0]_{color}
> {color:#00} {color}
> {color:#00}*Then client receives an channel closed exception:*{color}
> {color:#00} {color}
> {color:#00}*2018-02-21 18:43:30,764 [*{color}{color:#00}BitClient-4] 
> WARN  o.a.d.exec.rpc.RpcExceptionHandler - Exception occurred with closed 
> channel.  Connection: /_10.10.100.161:35482_ <--> _10.10.100.162:31012_ (data 
> client){color}
> {color:#00} {color}
> {color:#00}*and due to this it's initial command for authentication also 
> fails. Since there is channel closed exception above I will think that 
> triggered the failure of authentication request as well.*{color}
> {color:#00} {color}
> {color:#00}_Caused by: org.apache.drill.exec.rpc.RpcException: Command 
> failed while establishing connection.  Failure type AUTHENTICATION._{color}
> {color:#00}        _at 
> org.apache.drill.exec.rpc.RpcException.mapException(RpcException.java:67) 
> ~[drill-rpc-1.12.0-mapr.jar:1.12.0-mapr]_{color}
> {color:#00}        _at 
> org.apache.drill.exec.rpc.ListeningCommand.connectionFailed(ListeningCommand.java:66)
>  ~[drill-rpc-1.12.0-mapr.jar:1.12.0-mapr]_{color}
> {color:#00}        _at 
> org.apache.drill.exec.rpc.data.DataTunnel$SendBatchAsyncListen.connectionFailed(DataTunnel.java:166)
>  ~[drill-java-exec-1.12.0-mapr.jar:1.12.0-mapr]_{color}
> {color:#00}        _at 
> 

[jira] [Commented] (DRILL-6187) Exception in RPC communication between DataClient/ControlClient and respective servers when bit-to-bit security is on

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/drill/pull/1145#discussion_r173041172
  
--- Diff: 
exec/java-exec/src/main/java/org/apache/drill/exec/rpc/control/ControlClient.java
 ---
@@ -103,6 +96,23 @@ protected void handle(ControlConnection connection, int 
rpcType, ByteBuf pBody,
 connection.getCurrentHandler().handle(connection, rpcType, pBody, 
dBody, sender);
   }
 
+  @Override
+  protected void prepareSaslHandshake(final 
RpcConnectionHandler connectionListener)
--- End diff --

`RpcType.SASL_MESSAGE` message accessed within `prepareSaslHandshake` 
implementation of DataClient/ControlClient is defined separately. Also each of 
these client except UserClient has access to ConnectionConfig which is not part 
of BasicClient too and is used in prepareSaslHandshake implementation. Hence I 
kept the implementations separate for both DataClient and ControlClient.


> Exception in RPC communication between DataClient/ControlClient and 
> respective servers when bit-to-bit security is on
> -
>
> Key: DRILL-6187
> URL: https://issues.apache.org/jira/browse/DRILL-6187
> Project: Apache Drill
>  Issue Type: Bug
>  Components: Execution - RPC, Security
>Reporter: Sorabh Hamirwasia
>Assignee: Sorabh Hamirwasia
>Priority: Major
> Fix For: 1.13.0
>
>
>  
> {color:#00}Below is the summary of issue: {color}
>  
> {color:#00}*Scenario:*{color}
> {color:#00}It seems like first sendRecordBatch was sent to Foreman which 
> initiated the Authentication handshake. But before initiating handshake for 
> auth we establish a connection and store that in a registry. Now if in 
> parallel there is another recordBatch (by a different minor fragment running 
> on same Drillbit) to be sent then that will see the connection available in 
> registry and will initiate the send. Before the authentication is completed 
> this second request reached foreman and it throws below exception saying RPC 
> type 3 message is not allowed and closes the connection. This also fails the 
> authentication handshake which was in progress.{color}{color:#00} Here 
> the logs with details:{color}
> {color:#00} {color}
> {color:#00}*Forman received the SASL_START message from another 
> node:*{color}
> {color:#00}*_2018-02-21 18:43:30,759 
> [_*{color}{color:#00}_BitServer-4] TRACE 
> o.a.d.e.r.s.ServerAuthenticationHandler - Received SASL message SASL_START 
> from /10.10.100.161:35482_{color}
> {color:#00} {color}
> {color:#00}*Then around same time it received another message from client 
> of Rpc Type 3 which is for SendRecordBatch and fails since handshake is not 
> completed yet.*{color}
> {color:#00} {color}
> {color:#00}*_2018-02-21 18:43:30,762_*{color}{color:#00} 
> _[BitServer-4] ERROR o.a.d.exec.rpc.RpcExceptionHandler - Exception in RPC 
> communication.  Connection: /10.10.100.162:31012 <--> /__10.10.100.161:35482_ 
> _(data server).  Closing connection._{color}
> {color:#00}_io.netty.handler.codec.DecoderException: 
> org.apache.drill.exec.rpc.RpcException: Request of type 3 is not allowed 
> without authentication. Client on /__10.10.100.161:35482_ _must authenticate 
> before making requests. Connection dropped. [Details: Encryption: enabled , 
> MaxWrappedSize: 65536 , WrapSizeLimit: 0]_{color}
> {color:#00} {color}
> {color:#00}*Then client receives an channel closed exception:*{color}
> {color:#00} {color}
> {color:#00}*2018-02-21 18:43:30,764 [*{color}{color:#00}BitClient-4] 
> WARN  o.a.d.exec.rpc.RpcExceptionHandler - Exception occurred with closed 
> channel.  Connection: /_10.10.100.161:35482_ <--> _10.10.100.162:31012_ (data 
> client){color}
> {color:#00} {color}
> {color:#00}*and due to this it's initial command for authentication also 
> fails. Since there is channel closed exception above I will think that 
> triggered the failure of authentication request as well.*{color}
> {color:#00} {color}
> {color:#00}_Caused by: org.apache.drill.exec.rpc.RpcException: Command 
> failed while establishing connection.  Failure type AUTHENTICATION._{color}
> {color:#00}        _at 
> org.apache.drill.exec.rpc.RpcException.mapException(RpcException.java:67) 
> ~[drill-rpc-1.12.0-mapr.jar:1.12.0-mapr]_{color}
> {color:#00}        _at 
> org.apache.drill.exec.rpc.ListeningCommand.connectionFailed(ListeningCommand.java:66)
>  ~[drill-rpc-1.12.0-mapr.jar:1.12.0-mapr]_{color}
> {color:#00}       

[jira] [Commented] (DRILL-6187) Exception in RPC communication between DataClient/ControlClient and respective servers when bit-to-bit security is on

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/drill/pull/1145#discussion_r173041032
  
--- Diff: 
exec/java-exec/src/main/java/org/apache/drill/exec/client/DrillClient.java ---
@@ -371,17 +376,20 @@ protected void afterExecute(final Runnable r, final 
Throwable t) {
 
 while (triedEndpointIndex < connectTriesVal) {
   endpoint = endpoints.get(triedEndpointIndex);
+
+  // Set in both props and properties since props is passed to 
UserClient
+  if (!properties.containsKey(DrillProperties.SERVICE_HOST)) {
--- End diff --

`putIfAbsent` is Java 8 specific api. Today we had a discussion that until 
next release we don't want to bring dependency on Java 8 only api's.


> Exception in RPC communication between DataClient/ControlClient and 
> respective servers when bit-to-bit security is on
> -
>
> Key: DRILL-6187
> URL: https://issues.apache.org/jira/browse/DRILL-6187
> Project: Apache Drill
>  Issue Type: Bug
>  Components: Execution - RPC, Security
>Reporter: Sorabh Hamirwasia
>Assignee: Sorabh Hamirwasia
>Priority: Major
> Fix For: 1.13.0
>
>
>  
> {color:#00}Below is the summary of issue: {color}
>  
> {color:#00}*Scenario:*{color}
> {color:#00}It seems like first sendRecordBatch was sent to Foreman which 
> initiated the Authentication handshake. But before initiating handshake for 
> auth we establish a connection and store that in a registry. Now if in 
> parallel there is another recordBatch (by a different minor fragment running 
> on same Drillbit) to be sent then that will see the connection available in 
> registry and will initiate the send. Before the authentication is completed 
> this second request reached foreman and it throws below exception saying RPC 
> type 3 message is not allowed and closes the connection. This also fails the 
> authentication handshake which was in progress.{color}{color:#00} Here 
> the logs with details:{color}
> {color:#00} {color}
> {color:#00}*Forman received the SASL_START message from another 
> node:*{color}
> {color:#00}*_2018-02-21 18:43:30,759 
> [_*{color}{color:#00}_BitServer-4] TRACE 
> o.a.d.e.r.s.ServerAuthenticationHandler - Received SASL message SASL_START 
> from /10.10.100.161:35482_{color}
> {color:#00} {color}
> {color:#00}*Then around same time it received another message from client 
> of Rpc Type 3 which is for SendRecordBatch and fails since handshake is not 
> completed yet.*{color}
> {color:#00} {color}
> {color:#00}*_2018-02-21 18:43:30,762_*{color}{color:#00} 
> _[BitServer-4] ERROR o.a.d.exec.rpc.RpcExceptionHandler - Exception in RPC 
> communication.  Connection: /10.10.100.162:31012 <--> /__10.10.100.161:35482_ 
> _(data server).  Closing connection._{color}
> {color:#00}_io.netty.handler.codec.DecoderException: 
> org.apache.drill.exec.rpc.RpcException: Request of type 3 is not allowed 
> without authentication. Client on /__10.10.100.161:35482_ _must authenticate 
> before making requests. Connection dropped. [Details: Encryption: enabled , 
> MaxWrappedSize: 65536 , WrapSizeLimit: 0]_{color}
> {color:#00} {color}
> {color:#00}*Then client receives an channel closed exception:*{color}
> {color:#00} {color}
> {color:#00}*2018-02-21 18:43:30,764 [*{color}{color:#00}BitClient-4] 
> WARN  o.a.d.exec.rpc.RpcExceptionHandler - Exception occurred with closed 
> channel.  Connection: /_10.10.100.161:35482_ <--> _10.10.100.162:31012_ (data 
> client){color}
> {color:#00} {color}
> {color:#00}*and due to this it's initial command for authentication also 
> fails. Since there is channel closed exception above I will think that 
> triggered the failure of authentication request as well.*{color}
> {color:#00} {color}
> {color:#00}_Caused by: org.apache.drill.exec.rpc.RpcException: Command 
> failed while establishing connection.  Failure type AUTHENTICATION._{color}
> {color:#00}        _at 
> org.apache.drill.exec.rpc.RpcException.mapException(RpcException.java:67) 
> ~[drill-rpc-1.12.0-mapr.jar:1.12.0-mapr]_{color}
> {color:#00}        _at 
> org.apache.drill.exec.rpc.ListeningCommand.connectionFailed(ListeningCommand.java:66)
>  ~[drill-rpc-1.12.0-mapr.jar:1.12.0-mapr]_{color}
> {color:#00}        _at 
> org.apache.drill.exec.rpc.data.DataTunnel$SendBatchAsyncListen.connectionFailed(DataTunnel.java:166)
>  ~[drill-java-exec-1.12.0-mapr.jar:1.12.0-mapr]_{color}
> {color:#00}        

[jira] [Commented] (DRILL-6187) Exception in RPC communication between DataClient/ControlClient and respective servers when bit-to-bit security is on

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/drill/pull/1145#discussion_r173043030
  
--- Diff: 
exec/java-exec/src/main/java/org/apache/drill/exec/client/DrillClient.java ---
@@ -312,6 +312,11 @@ public synchronized void connect(String connect, 
Properties props) throws RpcExc
 if (connected) {
   return;
 }
+
+if (props == null) {
--- End diff --

Not totally sure what you mean here. Since there are 2 other overloaded 
methods which call's this method internally. They do pass null props and are 
used across multiple tests. 

May be I can check for props in those method instead and create a instance 
of it if needed ? Then we can place NotNull tag on this connect method. That 
will not require to change any existing tests.


> Exception in RPC communication between DataClient/ControlClient and 
> respective servers when bit-to-bit security is on
> -
>
> Key: DRILL-6187
> URL: https://issues.apache.org/jira/browse/DRILL-6187
> Project: Apache Drill
>  Issue Type: Bug
>  Components: Execution - RPC, Security
>Reporter: Sorabh Hamirwasia
>Assignee: Sorabh Hamirwasia
>Priority: Major
> Fix For: 1.13.0
>
>
>  
> {color:#00}Below is the summary of issue: {color}
>  
> {color:#00}*Scenario:*{color}
> {color:#00}It seems like first sendRecordBatch was sent to Foreman which 
> initiated the Authentication handshake. But before initiating handshake for 
> auth we establish a connection and store that in a registry. Now if in 
> parallel there is another recordBatch (by a different minor fragment running 
> on same Drillbit) to be sent then that will see the connection available in 
> registry and will initiate the send. Before the authentication is completed 
> this second request reached foreman and it throws below exception saying RPC 
> type 3 message is not allowed and closes the connection. This also fails the 
> authentication handshake which was in progress.{color}{color:#00} Here 
> the logs with details:{color}
> {color:#00} {color}
> {color:#00}*Forman received the SASL_START message from another 
> node:*{color}
> {color:#00}*_2018-02-21 18:43:30,759 
> [_*{color}{color:#00}_BitServer-4] TRACE 
> o.a.d.e.r.s.ServerAuthenticationHandler - Received SASL message SASL_START 
> from /10.10.100.161:35482_{color}
> {color:#00} {color}
> {color:#00}*Then around same time it received another message from client 
> of Rpc Type 3 which is for SendRecordBatch and fails since handshake is not 
> completed yet.*{color}
> {color:#00} {color}
> {color:#00}*_2018-02-21 18:43:30,762_*{color}{color:#00} 
> _[BitServer-4] ERROR o.a.d.exec.rpc.RpcExceptionHandler - Exception in RPC 
> communication.  Connection: /10.10.100.162:31012 <--> /__10.10.100.161:35482_ 
> _(data server).  Closing connection._{color}
> {color:#00}_io.netty.handler.codec.DecoderException: 
> org.apache.drill.exec.rpc.RpcException: Request of type 3 is not allowed 
> without authentication. Client on /__10.10.100.161:35482_ _must authenticate 
> before making requests. Connection dropped. [Details: Encryption: enabled , 
> MaxWrappedSize: 65536 , WrapSizeLimit: 0]_{color}
> {color:#00} {color}
> {color:#00}*Then client receives an channel closed exception:*{color}
> {color:#00} {color}
> {color:#00}*2018-02-21 18:43:30,764 [*{color}{color:#00}BitClient-4] 
> WARN  o.a.d.exec.rpc.RpcExceptionHandler - Exception occurred with closed 
> channel.  Connection: /_10.10.100.161:35482_ <--> _10.10.100.162:31012_ (data 
> client){color}
> {color:#00} {color}
> {color:#00}*and due to this it's initial command for authentication also 
> fails. Since there is channel closed exception above I will think that 
> triggered the failure of authentication request as well.*{color}
> {color:#00} {color}
> {color:#00}_Caused by: org.apache.drill.exec.rpc.RpcException: Command 
> failed while establishing connection.  Failure type AUTHENTICATION._{color}
> {color:#00}        _at 
> org.apache.drill.exec.rpc.RpcException.mapException(RpcException.java:67) 
> ~[drill-rpc-1.12.0-mapr.jar:1.12.0-mapr]_{color}
> {color:#00}        _at 
> org.apache.drill.exec.rpc.ListeningCommand.connectionFailed(ListeningCommand.java:66)
>  ~[drill-rpc-1.12.0-mapr.jar:1.12.0-mapr]_{color}
> {color:#00}        _at 
> org.apache.drill.exec.rpc.data.DataTunnel$SendBatchAsyncListen.connectionFailed(DataTunnel.java:166)
>  

[jira] [Commented] (DRILL-3548) Add/edit various Javadoc(/etc.) (plugin-exploration--related)

[Pritesh Maker (JIRA)]

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

Pritesh Maker commented on DRILL-3548:
--

[~amansinha100] this one is an old issue - it's in reviewable state - is it 
still relevant? 

> Add/edit various Javadoc(/etc.) (plugin-exploration--related)
> -
>
> Key: DRILL-3548
> URL: https://issues.apache.org/jira/browse/DRILL-3548
> Project: Apache Drill
>  Issue Type: Bug
>Reporter: Daniel Barclay
>Assignee: Aman Sinha
>Priority: Major
>




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

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

[Pritesh Maker (JIRA)]

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

Pritesh Maker updated DRILL-5365:
-
Reviewer: Paul Rogers

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



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

[jira] [Commented] (DRILL-6210) Enhance the test schema builder for remaining types

[ASF GitHub Bot (JIRA)]

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

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

Github user paul-rogers commented on the issue:

https://github.com/apache/drill/pull/1150
  
@Ben-Zvi, the changes look right. Old style was to have a "buildFoo" method 
for the nested structure "foo". The new style is to have a "resumeBar" method 
for the outer structure "bar".

If you have trouble, an alternative is to commit @ppadma's PR. Then I can 
immediately rebase and make the required fixes to her tests.


> Enhance the test schema builder for remaining types
> ---
>
> Key: DRILL-6210
> URL: https://issues.apache.org/jira/browse/DRILL-6210
> Project: Apache Drill
>  Issue Type: Improvement
>Reporter: Paul Rogers
>Assignee: Paul Rogers
>Priority: Major
>  Labels: ready-to-commit
> Fix For: 1.14.0
>
>
> The result set loader project enhanced the schema builder used in tests to 
> handle Drill's complex types: maps, unions, lists and repeated lists. The 
> schema builder previously only handled maps.
> This ticket describes the addition of just this one part of the result set 
> loader.
> Also adds a run-time schema improvement: functions to create arrays when 
> testing rather than writing out the {{new String[] \{"foo", "bar"\}}} syntax.



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

[jira] [Commented] (DRILL-6210) Enhance the test schema builder for remaining types

[ASF GitHub Bot (JIRA)]

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

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

Github user Ben-Zvi commented on the issue:

https://github.com/apache/drill/pull/1150
  
@paul-rogers this change also affects the new code (PR#1125) from @ppadma ; 
the required changes are proposed below; are these correct ?   Can you rebase ( 
#1125 should be committed soon), fix, squash, etc. ? 

```
--- 
a/exec/java-exec/src/test/java/org/apache/drill/exec/record/TestRecordBatchSizer.java
+++ 
b/exec/java-exec/src/test/java/org/apache/drill/exec/record/TestRecordBatchSizer.java
@@ -32,7 +32,7 @@ import org.apache.drill.test.SubOperatorTest;
 import org.apache.drill.test.rowSet.RowSet;
 import org.apache.drill.test.rowSet.RowSet.SingleRowSet;
 import org.apache.drill.test.rowSet.RowSetBuilder;
-import org.apache.drill.test.rowSet.SchemaBuilder;
+import org.apache.drill.test.rowSet.schema.SchemaBuilder;
 import org.junit.Test;

 public class TestRecordBatchSizer extends SubOperatorTest {
@@ -506,7 +506,7 @@ public class TestRecordBatchSizer extends 
SubOperatorTest {
   .addMap("map")
 .add("key", MinorType.INT)
 .add("value", MinorType.VARCHAR)
-  .buildMap()
+  .resumeSchema()
   .build();

 RowSetBuilder builder = fixture.rowSetBuilder(schema);
@@ -589,7 +589,7 @@ public class TestRecordBatchSizer extends 
SubOperatorTest {
 BatchSchema schema = new SchemaBuilder().addMapArray("map").
   add("key", MinorType.INT).
   add("value", MinorType.VARCHAR).
-  buildMap().build();
+  resumeSchema().build();

 RowSetBuilder builder = fixture.rowSetBuilder(schema);

@@ -694,8 +694,8 @@ public class TestRecordBatchSizer extends 
SubOperatorTest {
 .addMap("childMap")
   .add("childKey", MinorType.INT)
   .add("childValue", MinorType.VARCHAR)
-  .buildMap()
-   .buildMap()
+  .resumeMap()
+   .resumeSchema()
   .build();

 RowSetBuilder builder = fixture.rowSetBuilder(schema);
```


> Enhance the test schema builder for remaining types
> ---
>
> Key: DRILL-6210
> URL: https://issues.apache.org/jira/browse/DRILL-6210
> Project: Apache Drill
>  Issue Type: Improvement
>Reporter: Paul Rogers
>Assignee: Paul Rogers
>Priority: Major
>  Labels: ready-to-commit
> Fix For: 1.14.0
>
>
> The result set loader project enhanced the schema builder used in tests to 
> handle Drill's complex types: maps, unions, lists and repeated lists. The 
> schema builder previously only handled maps.
> This ticket describes the addition of just this one part of the result set 
> loader.
> Also adds a run-time schema improvement: functions to create arrays when 
> testing rather than writing out the {{new String[] \{"foo", "bar"\}}} syntax.



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

[jira] [Assigned] (DRILL-6183) Default value for parameter 'planner.width.max_per_node'

[Kunal Khatua (JIRA)]

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

Kunal Khatua reassigned DRILL-6183:
---

Assignee: Kunal Khatua

> Default value for parameter 'planner.width.max_per_node'
> 
>
> Key: DRILL-6183
> URL: https://issues.apache.org/jira/browse/DRILL-6183
> Project: Apache Drill
>  Issue Type: Bug
>  Components:  Server
>Affects Versions: 1.12.0
> Environment: Drill 1.12
>Reporter: Arjun
>Assignee: Kunal Khatua
>Priority: Minor
>
> The default value for configuration parameter 'planner.width.max_per_node' is 
> shown as 0 in Drill 1.12. In the previous versions, the default value is set 
> as 70% total core in the drillbit node.This could be confusing for users 
> upgrading from previous versions ( Whether it is unlimited value).  
> {code:java}
> 0: jdbc:drill:drillbit=localhost> select * from sys.options where name like 
> '%planner.width%'; 
> +--+---+---+--+--+--+-+---++
> | name | kind | accessibleScopes | optionScope | status | num_val | 
> string_val | bool_val | float_val |
> +--+---+---+--+--+--+-+---++
> | planner.width.max_per_node | LONG | ALL | BOOT | DEFAULT | 0 | null | null 
> | null |
> | planner.width.max_per_query | LONG | ALL | BOOT | DEFAULT | 1000 | null | 
> null | null |
> +--+---+---+--+--+--+-+---++
> 2 rows selected (0.913 seconds) 0: jdbc:drill:drillbit=localhost>
> {code}



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

[jira] [Updated] (DRILL-6183) Default value for parameter 'planner.width.max_per_node'

[Kunal Khatua (JIRA)]

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

Kunal Khatua updated DRILL-6183:

Description: 
The default value for configuration parameter 'planner.width.max_per_node' is 
shown as 0 in Drill 1.12. In the previous versions, the default value is set as 
70% total core in the drillbit node.This could be confusing for users upgrading 
from previous versions ( Whether it is unlimited value).  
{code:java}
0: jdbc:drill:drillbit=localhost> select * from sys.options where name like 
'%planner.width%'; 
+--+---+---+--+--+--+-+---++
| name | kind | accessibleScopes | optionScope | status | num_val | string_val 
| bool_val | float_val |
+--+---+---+--+--+--+-+---++
| planner.width.max_per_node | LONG | ALL | BOOT | DEFAULT | 0 | null | null | 
null |
| planner.width.max_per_query | LONG | ALL | BOOT | DEFAULT | 1000 | null | 
null | null |
+--+---+---+--+--+--+-+---++
2 rows selected (0.913 seconds) 0: jdbc:drill:drillbit=localhost>

{code}

  was:
The default value for configuration parameter 'planner.width.max_per_node' is 
shown as 0 in Drill 1.12. In the previous versions, the default value is set as 
70% total core in the drillbit node.This could be confusing for users upgrading 
from previous versions ( Whether it is unlimited value).  
{code:java}
0: jdbc:drill:drillbit=localhost> select * from sys.options where name like 
'%planner.width%'; 
+--+---+---+--+--+--+-+---++
 |            name            | kind  | accessibleScopes  | optionScope  |  
status  | num_val  | string_val  | bool_val  | float_val  | 
+--+---+---+--+--+--+-+---++
 | planner.width.max_per_node  | LONG  | ALL              | BOOT        | 
DEFAULT  | 0        | null        | null      | null      | | 
planner.width.max_per_query  | LONG  | ALL              | BOOT        | DEFAULT 
 | 1000    | null        | null      | null      | 
+--+---+---+--+--+--+-+---++
 2 rows selected (0.913 seconds) 0: jdbc:drill:drillbit=localhost>

{code}


> Default value for parameter 'planner.width.max_per_node'
> 
>
> Key: DRILL-6183
> URL: https://issues.apache.org/jira/browse/DRILL-6183
> Project: Apache Drill
>  Issue Type: Bug
>  Components:  Server
>Affects Versions: 1.12.0
> Environment: Drill 1.12
>Reporter: Arjun
>Priority: Minor
>
> The default value for configuration parameter 'planner.width.max_per_node' is 
> shown as 0 in Drill 1.12. In the previous versions, the default value is set 
> as 70% total core in the drillbit node.This could be confusing for users 
> upgrading from previous versions ( Whether it is unlimited value).  
> {code:java}
> 0: jdbc:drill:drillbit=localhost> select * from sys.options where name like 
> '%planner.width%'; 
> +--+---+---+--+--+--+-+---++
> | name | kind | accessibleScopes | optionScope | status | num_val | 
> string_val | bool_val | float_val |
> +--+---+---+--+--+--+-+---++
> | planner.width.max_per_node | LONG | ALL | BOOT | DEFAULT | 0 | null | null 
> | null |
> | planner.width.max_per_query | LONG | ALL | BOOT | DEFAULT | 1000 | null | 
> null | null |
> +--+---+---+--+--+--+-+---++
> 2 rows selected (0.913 seconds) 0: jdbc:drill:drillbit=localhost>
> {code}



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

[jira] [Commented] (DRILL-6044) Shutdown button does not work from WebUI

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/drill/pull/1153#discussion_r173031821
  
--- Diff: exec/java-exec/src/main/resources/rest/index.ftl ---
@@ -247,11 +253,14 @@
 $("#row-"+i).find("#queriesCount").text("");
 }
 else {
-if( status_map[key] == "ONLINE") {
+if (status_map[key] == "ONLINE") {
 $("#row-"+i).find("#status").text(status_map[key]);
 }
 else {
-fillQueryCount(address,i);
+var is_ssl_enabled = $('#ssl').val();
+if (is_ssl_enabled != "ssl_enabled") {
+fillQueryCount(address,i);
--- End diff --

`fillQueryCount` should also handle the case for Https and Http just like 
`shutdown`. Looks like currently with this change if SSL is enabled then we 
won't be able to get the queryCount of Drillbit shutting down.
Why not handle it in same way as for `shutdown` method ?


> Shutdown button does not work from WebUI
> 
>
> Key: DRILL-6044
> URL: https://issues.apache.org/jira/browse/DRILL-6044
> Project: Apache Drill
>  Issue Type: Bug
>  Components: Client - HTTP
>Affects Versions: 1.13.0
>Reporter: Krystal
>Assignee: Venkata Jyothsna Donapati
>Priority: Critical
> Fix For: 1.13.0
>
> Attachments: Screen Shot 2017-12-19 at 10.51.16 AM.png
>
>
> git.commit.id.abbrev=eb0c403
> Nothing happens when click on the SHUTDOWN button from the WebUI.  The 
> browser's debugger showed that the request failed due to access control 
> checks (see attached screen shot).



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

[jira] [Commented] (DRILL-6044) Shutdown button does not work from WebUI

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/drill/pull/1153#discussion_r173030603
  
--- Diff: exec/java-exec/src/main/resources/rest/index.ftl ---
@@ -272,6 +281,12 @@
<#if model.shouldShowAdminInfo()>
   function shutdown(address,button) {
   url = "http://"+address+":"+portNum+"/gracefulShutdown;;
+  var ssl = $('#ssl').val();
+  url = "http://;;
+  if (ssl == "ssl_enabled") {
+url = "https://;;
+  }
+  url = url+host+"/gracefulShutdown";
--- End diff --

I guess you can simplify the `shutdown` function as below.

```
function shutdown(button) {
 var protocol = location.protocol;
 var host = location.host;
 var requestPath = "/gracefulShutdown";
 var url = protocol+host+requestPath;
  ..
  
}
```



> Shutdown button does not work from WebUI
> 
>
> Key: DRILL-6044
> URL: https://issues.apache.org/jira/browse/DRILL-6044
> Project: Apache Drill
>  Issue Type: Bug
>  Components: Client - HTTP
>Affects Versions: 1.13.0
>Reporter: Krystal
>Assignee: Venkata Jyothsna Donapati
>Priority: Critical
> Fix For: 1.13.0
>
> Attachments: Screen Shot 2017-12-19 at 10.51.16 AM.png
>
>
> git.commit.id.abbrev=eb0c403
> Nothing happens when click on the SHUTDOWN button from the WebUI.  The 
> browser's debugger showed that the request failed due to access control 
> checks (see attached screen shot).



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

[jira] [Commented] (DRILL-6044) Shutdown button does not work from WebUI

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/drill/pull/1153#discussion_r173029148
  
--- Diff: exec/java-exec/src/main/resources/rest/index.ftl ---
@@ -272,6 +281,12 @@
<#if model.shouldShowAdminInfo()>
   function shutdown(address,button) {
   url = "http://"+address+":"+portNum+"/gracefulShutdown;;
+  var ssl = $('#ssl').val();
+  url = "http://;;
+  if (ssl == "ssl_enabled") {
+url = "https://;;
--- End diff --

Why not use 
[location.protocol](https://www.w3schools.com/jsref/prop_loc_protocol.asp) 
rather than getting the info from server side ?


> Shutdown button does not work from WebUI
> 
>
> Key: DRILL-6044
> URL: https://issues.apache.org/jira/browse/DRILL-6044
> Project: Apache Drill
>  Issue Type: Bug
>  Components: Client - HTTP
>Affects Versions: 1.13.0
>Reporter: Krystal
>Assignee: Venkata Jyothsna Donapati
>Priority: Critical
> Fix For: 1.13.0
>
> Attachments: Screen Shot 2017-12-19 at 10.51.16 AM.png
>
>
> git.commit.id.abbrev=eb0c403
> Nothing happens when click on the SHUTDOWN button from the WebUI.  The 
> browser's debugger showed that the request failed due to access control 
> checks (see attached screen shot).



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

[jira] [Commented] (DRILL-6044) Shutdown button does not work from WebUI

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/drill/pull/1153#discussion_r173029876
  
--- Diff: exec/java-exec/src/main/resources/rest/index.ftl ---
@@ -272,6 +281,12 @@
<#if model.shouldShowAdminInfo()>
   function shutdown(address,button) {
   url = "http://"+address+":"+portNum+"/gracefulShutdown;;
--- End diff --

please delete this line and update the `shutdown` signature since `address` 
is not needed anymore.


> Shutdown button does not work from WebUI
> 
>
> Key: DRILL-6044
> URL: https://issues.apache.org/jira/browse/DRILL-6044
> Project: Apache Drill
>  Issue Type: Bug
>  Components: Client - HTTP
>Affects Versions: 1.13.0
>Reporter: Krystal
>Assignee: Venkata Jyothsna Donapati
>Priority: Critical
> Fix For: 1.13.0
>
> Attachments: Screen Shot 2017-12-19 at 10.51.16 AM.png
>
>
> git.commit.id.abbrev=eb0c403
> Nothing happens when click on the SHUTDOWN button from the WebUI.  The 
> browser's debugger showed that the request failed due to access control 
> checks (see attached screen shot).



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

[jira] [Updated] (DRILL-6216) Metadata mismatch when connecting to a Drill 1.12.0 with a Drill-1.13.0-SNAPSHOT driver

[Pritesh Maker (JIRA)]

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

Pritesh Maker updated DRILL-6216:
-
Labels: ready-to-commit  (was: )

> Metadata mismatch when connecting to a Drill 1.12.0 with a 
> Drill-1.13.0-SNAPSHOT driver
> ---
>
> Key: DRILL-6216
> URL: https://issues.apache.org/jira/browse/DRILL-6216
> Project: Apache Drill
>  Issue Type: Bug
>  Components: Client - JDBC
>Affects Versions: 1.13.0
>Reporter: Kunal Khatua
>Assignee: Sorabh Hamirwasia
>Priority: Blocker
>  Labels: ready-to-commit
> Fix For: 1.13.0
>
>
> When running against a 1.12.0 Drill server
> {code:sql}
>  select * from sys.`options`;
> {code}
> I hit the following issue in Squirrel-SQL client with the 1.13.0-SNAPSHOT 
> JDBC driver.
> {code:java}
> 2018-02-20 11:41:16,557 [Thread-2] DEBUG 
> net.sourceforge.squirrel_sql.fw.util.DefaultExceptionFormatter  - Error
> java.sql.SQLException: Unexpected RuntimeException: 
> java.lang.IllegalArgumentException: The field [`$values$` (BIGINT:OPTIONAL)] 
> doesn't match the provided metadata major_type {
>   minor_type: BIGINT
>   mode: OPTIONAL
> }
> name_part {
>   name: "num_val"
> }
> value_count: 153
> buffer_length: 1224
> .
>   at 
> org.apache.drill.jdbc.impl.DrillCursor.nextRowInternally(DrillCursor.java:544)
>   at 
> org.apache.drill.jdbc.impl.DrillCursor.loadInitialSchema(DrillCursor.java:602)
>   at 
> org.apache.drill.jdbc.impl.DrillResultSetImpl.execute(DrillResultSetImpl.java:1918)
>   at 
> org.apache.drill.jdbc.impl.DrillResultSetImpl.execute(DrillResultSetImpl.java:66)
>   at 
> oadd.org.apache.calcite.avatica.AvaticaConnection$1.execute(AvaticaConnection.java:630)
>   at 
> org.apache.drill.jdbc.impl.DrillMetaImpl.prepareAndExecute(DrillMetaImpl.java:1106)
>   at 
> org.apache.drill.jdbc.impl.DrillMetaImpl.prepareAndExecute(DrillMetaImpl.java:1117)
>   at 
> oadd.org.apache.calcite.avatica.AvaticaConnection.prepareAndExecuteInternal(AvaticaConnection.java:638)
>   at 
> org.apache.drill.jdbc.impl.DrillConnectionImpl.prepareAndExecuteInternal(DrillConnectionImpl.java:193)
>   at 
> oadd.org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:149)
>   at 
> oadd.org.apache.calcite.avatica.AvaticaStatement.execute(AvaticaStatement.java:209)
>   at 
> org.apache.drill.jdbc.impl.DrillStatementImpl.execute(DrillStatementImpl.java:101)
>   at 
> net.sourceforge.squirrel_sql.client.session.StatementWrapper.execute(StatementWrapper.java:165)
>   at 
> net.sourceforge.squirrel_sql.client.session.SQLExecuterTask.processQuery(SQLExecuterTask.java:378)
>   at 
> net.sourceforge.squirrel_sql.client.session.SQLExecuterTask.run(SQLExecuterTask.java:221)
>   at 
> net.sourceforge.squirrel_sql.fw.util.TaskExecuter.run(TaskExecuter.java:82)
>   at java.lang.Thread.run(Unknown Source)
> Caused by: java.lang.IllegalArgumentException: The field [`$values$` 
> (BIGINT:OPTIONAL)] doesn't match the provided metadata major_type {
>   minor_type: BIGINT
>   mode: OPTIONAL
> }
> name_part {
>   name: "num_val"
> }
> value_count: 153
> buffer_length: 1224
> .
>   at 
> oadd.com.google.common.base.Preconditions.checkArgument(Preconditions.java:145)
>   at 
> oadd.org.apache.drill.exec.vector.BigIntVector.load(BigIntVector.java:299)
>   at 
> oadd.org.apache.drill.exec.vector.NullableBigIntVector.load(NullableBigIntVector.java:295)
>   at 
> oadd.org.apache.drill.exec.record.RecordBatchLoader.load(RecordBatchLoader.java:135)
>   at 
> org.apache.drill.jdbc.impl.DrillCursor.nextRowInternally(DrillCursor.java:506)
>   ... 16 more
> {code}
> This issue however, doesn't exist when working with Apache Master 
> 1.13.0-SNAPSHOT



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

[jira] [Updated] (DRILL-6202) Deprecate usage of IndexOutOfBoundsException to re-alloc vectors

[Pritesh Maker (JIRA)]

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

Pritesh Maker updated DRILL-6202:
-
Fix Version/s: (was: 1.13.0)
   1.14.0

> Deprecate usage of IndexOutOfBoundsException to re-alloc vectors
> 
>
> Key: DRILL-6202
> URL: https://issues.apache.org/jira/browse/DRILL-6202
> Project: Apache Drill
>  Issue Type: Bug
>Reporter: Vlad Rozov
>Assignee: Vlad Rozov
>Priority: Major
> Fix For: 1.14.0
>
>
> As bounds checking may be enabled or disabled, using 
> IndexOutOfBoundsException to resize vectors is unreliable. It works only when 
> bounds checking is enabled.



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

[jira] [Updated] (DRILL-5310) Memory leak in managed sort if OOM during sv2 allocation

[Pritesh Maker (JIRA)]

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

Pritesh Maker updated DRILL-5310:
-
Fix Version/s: (was: 1.13.0)

> Memory leak in managed sort if OOM during sv2 allocation
> 
>
> Key: DRILL-5310
> URL: https://issues.apache.org/jira/browse/DRILL-5310
> Project: Apache Drill
>  Issue Type: Sub-task
>Affects Versions: 1.10.0
>Reporter: Paul Rogers
>Assignee: Paul Rogers
>Priority: Major
>
> See the "identical1" test case in DRILL-5266. Due to misconfiguration, the 
> sort was given too little memory to make progress. An OOM error occurred when 
> allocating an SV2.
> In this scenario, the "converted" record batch is leaked.
> Normally, a converted batch is added to the list of in-memory batches, then 
> released on {{close()}}. But, in this case, the batch is only a local 
> variable, and so leaks.
> The code must release this batch in this condition.



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

[jira] [Updated] (DRILL-6203) Repeated Map Vector does not give correct payload bytecount.

[Pritesh Maker (JIRA)]

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

Pritesh Maker updated DRILL-6203:
-
Fix Version/s: (was: 1.13.0)
   1.14.0

> Repeated Map Vector does not give correct payload bytecount. 
> -
>
> Key: DRILL-6203
> URL: https://issues.apache.org/jira/browse/DRILL-6203
> Project: Apache Drill
>  Issue Type: Bug
>  Components: Execution - Flow
>Affects Versions: 1.12.0
>Reporter: Padma Penumarthy
>Assignee: Padma Penumarthy
>Priority: Major
> Fix For: 1.14.0
>
>
> Repeated Map Vector does not give correct payload byte count. It calls 
> abstractMapVector method which gives payload byte count for a given value 
> count for simple map (non repetitive) case. We need to overload this method 
> for repeated map to get the right numbers. 
> Also, Repeated Map and Repeated List vectors implement 
> RepeatedFixedWidthVectorLike and that causes problems when doing memory 
> allocation with AllocationHelper routines for those vectors. 



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

[jira] [Updated] (DRILL-5848) Implement Parquet Columnar Processing & Use Bulk APIs for processing

[Pritesh Maker (JIRA)]

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

Pritesh Maker updated DRILL-5848:
-
Fix Version/s: (was: 1.13.0)

> Implement Parquet Columnar Processing & Use Bulk APIs for processing
> 
>
> Key: DRILL-5848
> URL: https://issues.apache.org/jira/browse/DRILL-5848
> Project: Apache Drill
>  Issue Type: Sub-task
>  Components: Storage - Parquet
>Affects Versions: 1.11.0
>Reporter: salim achouche
>Assignee: salim achouche
>Priority: Major
>
> * Change Flat Parquet Reader processing from row based to columnar
> * Use Bulk APIs during the parsing and data loading phase



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

[jira] [Commented] (DRILL-6216) Metadata mismatch when connecting to a Drill 1.12.0 with a Drill-1.13.0-SNAPSHOT driver

[ASF GitHub Bot (JIRA)]

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

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

Github user amansinha100 commented on the issue:

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


> Metadata mismatch when connecting to a Drill 1.12.0 with a 
> Drill-1.13.0-SNAPSHOT driver
> ---
>
> Key: DRILL-6216
> URL: https://issues.apache.org/jira/browse/DRILL-6216
> Project: Apache Drill
>  Issue Type: Bug
>  Components: Client - JDBC
>Affects Versions: 1.13.0
>Reporter: Kunal Khatua
>Assignee: Sorabh Hamirwasia
>Priority: Blocker
> Fix For: 1.13.0
>
>
> When running against a 1.12.0 Drill server
> {code:sql}
>  select * from sys.`options`;
> {code}
> I hit the following issue in Squirrel-SQL client with the 1.13.0-SNAPSHOT 
> JDBC driver.
> {code:java}
> 2018-02-20 11:41:16,557 [Thread-2] DEBUG 
> net.sourceforge.squirrel_sql.fw.util.DefaultExceptionFormatter  - Error
> java.sql.SQLException: Unexpected RuntimeException: 
> java.lang.IllegalArgumentException: The field [`$values$` (BIGINT:OPTIONAL)] 
> doesn't match the provided metadata major_type {
>   minor_type: BIGINT
>   mode: OPTIONAL
> }
> name_part {
>   name: "num_val"
> }
> value_count: 153
> buffer_length: 1224
> .
>   at 
> org.apache.drill.jdbc.impl.DrillCursor.nextRowInternally(DrillCursor.java:544)
>   at 
> org.apache.drill.jdbc.impl.DrillCursor.loadInitialSchema(DrillCursor.java:602)
>   at 
> org.apache.drill.jdbc.impl.DrillResultSetImpl.execute(DrillResultSetImpl.java:1918)
>   at 
> org.apache.drill.jdbc.impl.DrillResultSetImpl.execute(DrillResultSetImpl.java:66)
>   at 
> oadd.org.apache.calcite.avatica.AvaticaConnection$1.execute(AvaticaConnection.java:630)
>   at 
> org.apache.drill.jdbc.impl.DrillMetaImpl.prepareAndExecute(DrillMetaImpl.java:1106)
>   at 
> org.apache.drill.jdbc.impl.DrillMetaImpl.prepareAndExecute(DrillMetaImpl.java:1117)
>   at 
> oadd.org.apache.calcite.avatica.AvaticaConnection.prepareAndExecuteInternal(AvaticaConnection.java:638)
>   at 
> org.apache.drill.jdbc.impl.DrillConnectionImpl.prepareAndExecuteInternal(DrillConnectionImpl.java:193)
>   at 
> oadd.org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:149)
>   at 
> oadd.org.apache.calcite.avatica.AvaticaStatement.execute(AvaticaStatement.java:209)
>   at 
> org.apache.drill.jdbc.impl.DrillStatementImpl.execute(DrillStatementImpl.java:101)
>   at 
> net.sourceforge.squirrel_sql.client.session.StatementWrapper.execute(StatementWrapper.java:165)
>   at 
> net.sourceforge.squirrel_sql.client.session.SQLExecuterTask.processQuery(SQLExecuterTask.java:378)
>   at 
> net.sourceforge.squirrel_sql.client.session.SQLExecuterTask.run(SQLExecuterTask.java:221)
>   at 
> net.sourceforge.squirrel_sql.fw.util.TaskExecuter.run(TaskExecuter.java:82)
>   at java.lang.Thread.run(Unknown Source)
> Caused by: java.lang.IllegalArgumentException: The field [`$values$` 
> (BIGINT:OPTIONAL)] doesn't match the provided metadata major_type {
>   minor_type: BIGINT
>   mode: OPTIONAL
> }
> name_part {
>   name: "num_val"
> }
> value_count: 153
> buffer_length: 1224
> .
>   at 
> oadd.com.google.common.base.Preconditions.checkArgument(Preconditions.java:145)
>   at 
> oadd.org.apache.drill.exec.vector.BigIntVector.load(BigIntVector.java:299)
>   at 
> oadd.org.apache.drill.exec.vector.NullableBigIntVector.load(NullableBigIntVector.java:295)
>   at 
> oadd.org.apache.drill.exec.record.RecordBatchLoader.load(RecordBatchLoader.java:135)
>   at 
> org.apache.drill.jdbc.impl.DrillCursor.nextRowInternally(DrillCursor.java:506)
>   ... 16 more
> {code}
> This issue however, doesn't exist when working with Apache Master 
> 1.13.0-SNAPSHOT



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

[jira] [Updated] (DRILL-6203) Repeated Map Vector does not give correct payload bytecount.

[Boaz Ben-Zvi (JIRA)]

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

Boaz Ben-Zvi updated DRILL-6203:

Fix Version/s: 1.13.0

> Repeated Map Vector does not give correct payload bytecount. 
> -
>
> Key: DRILL-6203
> URL: https://issues.apache.org/jira/browse/DRILL-6203
> Project: Apache Drill
>  Issue Type: Bug
>  Components: Execution - Flow
>Affects Versions: 1.12.0
>Reporter: Padma Penumarthy
>Assignee: Padma Penumarthy
>Priority: Major
> Fix For: 1.13.0
>
>
> Repeated Map Vector does not give correct payload byte count. It calls 
> abstractMapVector method which gives payload byte count for a given value 
> count for simple map (non repetitive) case. We need to overload this method 
> for repeated map to get the right numbers. 
> Also, Repeated Map and Repeated List vectors implement 
> RepeatedFixedWidthVectorLike and that causes problems when doing memory 
> allocation with AllocationHelper routines for those vectors. 



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

[jira] [Updated] (DRILL-6177) Merge Join - Allocate memory for outgoing value vectors based on sizes of incoming batches.

[Boaz Ben-Zvi (JIRA)]

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

Boaz Ben-Zvi updated DRILL-6177:

Fix Version/s: (was: 1.14.0)
   1.13.0

> Merge Join - Allocate memory for outgoing value vectors based on sizes of 
> incoming batches.
> ---
>
> Key: DRILL-6177
> URL: https://issues.apache.org/jira/browse/DRILL-6177
> Project: Apache Drill
>  Issue Type: Improvement
>  Components: Execution - Flow
>Affects Versions: 1.12.0
>Reporter: Padma Penumarthy
>Assignee: Padma Penumarthy
>Priority: Major
> Fix For: 1.13.0
>
>
> Merge join currently assigns memory by default for 64k rows. Change this to 
> assign memory for vectors based on number of rows in the outgoing batch and 
> sizing information of each column. 



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

[jira] [Commented] (DRILL-6216) Metadata mismatch when connecting to a Drill 1.12.0 with a Drill-1.13.0-SNAPSHOT driver

[ASF GitHub Bot (JIRA)]

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

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

GitHub user sohami opened a pull request:

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

DRILL-6216: Metadata mismatch when connecting to a Drill 1.12.0 with …

…a Drill-1.13.0-SNAPSHOT driver

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

$ git pull https://github.com/sohami/drill DRILL-6216

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

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


commit fddde494554e74ff4f3fba89f2916900e4e2f917
Author: Sorabh Hamirwasia 
Date:   2018-03-07T20:06:32Z

DRILL-6216: Metadata mismatch when connecting to a Drill 1.12.0 with a 
Drill-1.13.0-SNAPSHOT driver




> Metadata mismatch when connecting to a Drill 1.12.0 with a 
> Drill-1.13.0-SNAPSHOT driver
> ---
>
> Key: DRILL-6216
> URL: https://issues.apache.org/jira/browse/DRILL-6216
> Project: Apache Drill
>  Issue Type: Bug
>  Components: Client - JDBC
>Affects Versions: 1.13.0
>Reporter: Kunal Khatua
>Assignee: Sorabh Hamirwasia
>Priority: Blocker
> Fix For: 1.13.0
>
>
> When running against a 1.12.0 Drill server
> {code:sql}
>  select * from sys.`options`;
> {code}
> I hit the following issue in Squirrel-SQL client with the 1.13.0-SNAPSHOT 
> JDBC driver.
> {code:java}
> 2018-02-20 11:41:16,557 [Thread-2] DEBUG 
> net.sourceforge.squirrel_sql.fw.util.DefaultExceptionFormatter  - Error
> java.sql.SQLException: Unexpected RuntimeException: 
> java.lang.IllegalArgumentException: The field [`$values$` (BIGINT:OPTIONAL)] 
> doesn't match the provided metadata major_type {
>   minor_type: BIGINT
>   mode: OPTIONAL
> }
> name_part {
>   name: "num_val"
> }
> value_count: 153
> buffer_length: 1224
> .
>   at 
> org.apache.drill.jdbc.impl.DrillCursor.nextRowInternally(DrillCursor.java:544)
>   at 
> org.apache.drill.jdbc.impl.DrillCursor.loadInitialSchema(DrillCursor.java:602)
>   at 
> org.apache.drill.jdbc.impl.DrillResultSetImpl.execute(DrillResultSetImpl.java:1918)
>   at 
> org.apache.drill.jdbc.impl.DrillResultSetImpl.execute(DrillResultSetImpl.java:66)
>   at 
> oadd.org.apache.calcite.avatica.AvaticaConnection$1.execute(AvaticaConnection.java:630)
>   at 
> org.apache.drill.jdbc.impl.DrillMetaImpl.prepareAndExecute(DrillMetaImpl.java:1106)
>   at 
> org.apache.drill.jdbc.impl.DrillMetaImpl.prepareAndExecute(DrillMetaImpl.java:1117)
>   at 
> oadd.org.apache.calcite.avatica.AvaticaConnection.prepareAndExecuteInternal(AvaticaConnection.java:638)
>   at 
> org.apache.drill.jdbc.impl.DrillConnectionImpl.prepareAndExecuteInternal(DrillConnectionImpl.java:193)
>   at 
> oadd.org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:149)
>   at 
> oadd.org.apache.calcite.avatica.AvaticaStatement.execute(AvaticaStatement.java:209)
>   at 
> org.apache.drill.jdbc.impl.DrillStatementImpl.execute(DrillStatementImpl.java:101)
>   at 
> net.sourceforge.squirrel_sql.client.session.StatementWrapper.execute(StatementWrapper.java:165)
>   at 
> net.sourceforge.squirrel_sql.client.session.SQLExecuterTask.processQuery(SQLExecuterTask.java:378)
>   at 
> net.sourceforge.squirrel_sql.client.session.SQLExecuterTask.run(SQLExecuterTask.java:221)
>   at 
> net.sourceforge.squirrel_sql.fw.util.TaskExecuter.run(TaskExecuter.java:82)
>   at java.lang.Thread.run(Unknown Source)
> Caused by: java.lang.IllegalArgumentException: The field [`$values$` 
> (BIGINT:OPTIONAL)] doesn't match the provided metadata major_type {
>   minor_type: BIGINT
>   mode: OPTIONAL
> }
> name_part {
>   name: "num_val"
> }
> value_count: 153
> buffer_length: 1224
> .
>   at 
> oadd.com.google.common.base.Preconditions.checkArgument(Preconditions.java:145)
>   at 
> oadd.org.apache.drill.exec.vector.BigIntVector.load(BigIntVector.java:299)
>   at 
> oadd.org.apache.drill.exec.vector.NullableBigIntVector.load(NullableBigIntVector.java:295)
>   at 
> oadd.org.apache.drill.exec.record.RecordBatchLoader.load(RecordBatchLoader.java:135)
>   at 
> org.apache.drill.jdbc.impl.DrillCursor.nextRowInternally(DrillCursor.java:506)
>   ... 16 more
> {code}
> This issue however, doesn't exist when working with Apache Master 
> 1.13.0-SNAPSHOT



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

[jira] [Assigned] (DRILL-5918) Allow manual configuration when using Runtime.getRuntime().availableProcessors()

[Pritesh Maker (JIRA)]

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

Pritesh Maker reassigned DRILL-5918:


Assignee: Karthikeyan Manivannan

> Allow manual configuration when using 
> Runtime.getRuntime().availableProcessors()
> 
>
> Key: DRILL-5918
> URL: https://issues.apache.org/jira/browse/DRILL-5918
> Project: Apache Drill
>  Issue Type: Improvement
>Affects Versions: 1.11.0
>Reporter: Elijah Zupancic
>Assignee: Karthikeyan Manivannan
>Priority: Critical
>
> Currently Drill auto-configures the number of threads in various thread pools 
> based on the processor count:
> https://github.com/apache/drill/blob/master/exec/java-exec/src/main/java/org/apache/drill/exec/server/BootStrapContext.java#L110
> https://github.com/apache/drill/blob/master/exec/java-exec/src/main/java/org/apache/drill/exec/server/options/TypeValidators.java#L269
> https://github.com/apache/drill/blob/master/exec/java-exec/src/main/java/org/apache/drill/exec/work/foreman/rm/AbstractResourceManager.java#L55
> https://github.com/apache/drill/blob/master/exec/java-exec/src/main/java/org/apache/drill/exec/work/foreman/rm/DefaultResourceManager.java#L99
> In a number of situations, this configuration is incorrect. In particular, 
> the settings aren't correct when [running in a bare-metal 
> container](https://docs.google.com/document/d/1WGPGiJtbJZPZBMSD9YHAAz-O4AlAET9qOnS_GeriZtE/edit?usp=sharing)
>  because you don't necessarily have access to all of the compute shares or 
> memory of the underlying host.
> Ideally, the number of CPUs to use could be specified as a system parameter 
> to Drill. This would allow users to configure Drill to their optimal settings.



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

[jira] [Assigned] (DRILL-3440) Canceling queries on Sqlline crashes all Drillbits with unsafe memory access disabled

[Pritesh Maker (JIRA)]

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

Pritesh Maker reassigned DRILL-3440:


Assignee: Karthikeyan Manivannan  (was: Parth Chandra)

> Canceling queries on Sqlline crashes all Drillbits with unsafe memory access 
> disabled
> -
>
> Key: DRILL-3440
> URL: https://issues.apache.org/jira/browse/DRILL-3440
> Project: Apache Drill
>  Issue Type: Bug
>  Components: Execution - Flow
>Reporter: Abhishek Girish
>Assignee: Karthikeyan Manivannan
>Priority: Critical
> Fix For: Future
>
> Attachments: drillbit.log.txt, drillbit.out.txt, hs_error.log
>
>
> Upon canceling a query all drillbits crash. 
> {code:sql}
> > SELECT RANK() OVER (PARTITION BY ss.ss_store_sk ORDER BY ss.ss_store_sk), 
> > AVG(ss_ext_discount_amt) OVER (PARTITION BY ss.ss_store_sk ORDER BY 
> > ss.ss_store_sk) FROM store_sales ss WHERE ss.ss_store_sk is not NULL LIMIT 
> > 20;
> [Cancel]
> {code}
> Upon reissuing a query, I see an error with connection. Upon inspection, all 
> drillbits were down. There was a JVM crash. 
> {code:sql}
> > select * from store_sales limit 1;
> Error: CONNECTION ERROR: Connection /10.10.120.101:55788 <--> 
> /10.10.120.110:31010 (user client) closed unexpectedly.
> [Error Id: 6dfd9fef-39bf-4955-8783-49805e1a8e3d ] (state=,code=0)
> {code}
> Logs attached. 



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

[jira] [Assigned] (DRILL-520) ceiling/ceil and floor functions return decimal value instead of an integer

[Pritesh Maker (JIRA)]

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

Pritesh Maker reassigned DRILL-520:
---

Assignee: Karthikeyan Manivannan  (was: Jinfeng Ni)

> ceiling/ceil and floor functions return decimal value instead of an integer
> ---
>
> Key: DRILL-520
> URL: https://issues.apache.org/jira/browse/DRILL-520
> Project: Apache Drill
>  Issue Type: Bug
>  Components: Functions - Drill
>Affects Versions: 1.0.0
>Reporter: Krystal
>Assignee: Karthikeyan Manivannan
>Priority: Critical
> Fix For: Future
>
> Attachments: DRILL-520.patch
>
>
> Ran the following queries in drill:
> 0: jdbc:drill:schema=dfs> select ceiling(55.8) from dfs.`student` where 
> rownum=11;
> ++
> |   EXPR$0   |
> ++
> | 56.0   |
> ++
> 0: jdbc:drill:schema=dfs> select floor(55.8) from dfs.`student` where 
> rownum=11;
> ++
> |   EXPR$0   |
> ++
> | 55.0   |
> ++
> The same queries executed from oracle, postgres and mysql returned integer 
> values of 56 and 55.
> Found the following description of the two functions from 
> http://users.atw.hu/sqlnut/sqlnut2-chp-4-sect-4.html :
> Ceil/Ceiling:
> Rounds a noninteger value upwards to the next greatest integer. Returns an 
> integer value unchanged.
> Floor:
> Rounds a noninteger value downwards to the next least integer. Returns an 
> integer value unchanged.



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

[jira] [Assigned] (DRILL-5581) Query with CASE statement returns wrong results

[Pritesh Maker (JIRA)]

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

Pritesh Maker reassigned DRILL-5581:


Assignee: Karthikeyan Manivannan  (was: Volodymyr Vysotskyi)

> Query with CASE statement returns wrong results
> ---
>
> Key: DRILL-5581
> URL: https://issues.apache.org/jira/browse/DRILL-5581
> Project: Apache Drill
>  Issue Type: Bug
>  Components: Execution - Flow
>Affects Versions: 1.11.0
>Reporter: Khurram Faraaz
>Assignee: Karthikeyan Manivannan
>Priority: Major
>
> A query that uses case statement, returns wrong results.
> {noformat}
> Apache Drill 1.11.0-SNAPSHOT, commit id: 874bf629
> [test@centos-101 ~]# cat order_sample.csv
> 202634342,2101,20160301
> apache drill 1.11.0-SNAPSHOT
> "this isn't your grandfather's sql"
> 0: jdbc:drill:schema=dfs.tmp> ALTER SESSION SET `store.format`='csv';
> +---++
> |  ok   |summary |
> +---++
> | true  | store.format updated.  |
> +---++
> 1 row selected (0.245 seconds)
> 0: jdbc:drill:schema=dfs.tmp> CREATE VIEW  `vw_order_sample_csv` as
> . . . . . . . . . . . . . . > SELECT
> . . . . . . . . . . . . . . > `columns`[0] AS `ND`,
> . . . . . . . . . . . . . . > CAST(`columns`[1] AS BIGINT) AS `col1`,
> . . . . . . . . . . . . . . > CAST(`columns`[2] AS BIGINT) AS `col2`
> . . . . . . . . . . . . . . > FROM `order_sample.csv`;
> +---+--+
> |  ok   |   summary   
>  |
> +---+--+
> | true  | View 'vw_order_sample_csv' created successfully in 'dfs.tmp' schema 
>  |
> +---+--+
> 1 row selected (0.253 seconds)
> 0: jdbc:drill:schema=dfs.tmp> select
> . . . . . . . . . . . . . . > case
> . . . . . . . . . . . . . . > when col1 > col2 then col1
> . . . . . . . . . . . . . . > else col2
> . . . . . . . . . . . . . . > end as temp_col,
> . . . . . . . . . . . . . . > case
> . . . . . . . . . . . . . . > when col1 = 2101 and (20170302 - col2) > 
> 1 then 'D'
> . . . . . . . . . . . . . . > when col2 = 2101 then 'P'
> . . . . . . . . . . . . . . > when col1 - col2 > 1 then '0'
> . . . . . . . . . . . . . . > else 'A'
> . . . . . . . . . . . . . . > end as status
> . . . . . . . . . . . . . . > from  `vw_order_sample_csv`;
> +---+-+
> | temp_col  | status  |
> +---+-+
> | 20160301  | A   |
> +---+-+
> 1 row selected (0.318 seconds)
> 0: jdbc:drill:schema=dfs.tmp> explain plan for
> . . . . . . . . . . . . . . > select
> . . . . . . . . . . . . . . > case
> . . . . . . . . . . . . . . > when col1 > col2 then col1
> . . . . . . . . . . . . . . > else col2
> . . . . . . . . . . . . . . > end as temp_col,
> . . . . . . . . . . . . . . > case
> . . . . . . . . . . . . . . > when col1 = 2101 and (20170302 - col2) > 
> 1 then 'D'
> . . . . . . . . . . . . . . > when col2 = 2101 then 'P'
> . . . . . . . . . . . . . . > when col1 - col2 > 1 then '0'
> . . . . . . . . . . . . . . > else 'A'
> . . . . . . . . . . . . . . > end as status
> . . . . . . . . . . . . . . > from  `vw_order_sample_csv`;
> +--+--+
> | text | json |
> +--+--+
> | 00-00Screen
> 00-01  Project(temp_col=[CASE(>(CAST(ITEM($0, 1)):BIGINT, CAST(ITEM($0, 
> 2)):BIGINT), CAST(ITEM($0, 1)):BIGINT, CAST(ITEM($0, 2)):BIGINT)], 
> status=[CASE(AND(=(CAST(ITEM($0, 1)):BIGINT, 2101), >(-(20170302, 
> CAST(ITEM($0, 2)):BIGINT), 1)), 'D', =(CAST(ITEM($0, 2)):BIGINT, 
> 2101), 'P', >(-(CAST(ITEM($0, 1)):BIGINT, CAST(ITEM($0, 2)):BIGINT), 
> 1), '0', 'A')])
> 00-02Scan(groupscan=[EasyGroupScan 
> [selectionRoot=maprfs:/tmp/order_sample.csv, numFiles=1, 
> columns=[`columns`[1], `columns`[2]], 
> files=[maprfs:///tmp/order_sample.csv]]])
> // Details of Java compiler from sys.options
> 0: jdbc:drill:schema=dfs.tmp> select name, status from sys.options where name 
> like '%java_compiler%';
> ++--+
> |  name  |  status  |
> ++--+
> | exec.java.compiler.exp_in_method_size  | DEFAULT  |
> | exec.java_compiler | DEFAULT  |
> | exec.java_compiler_debug   | DEFAULT  |
> | exec.java_compiler_janino_maxsize  | DEFAULT  |
> ++--+
> 4 rows selected (0.21 seconds)
> {noformat}
> Results from Postgres 9.3 for the same query, note the difference in results
> {noformat}
> postgres=# create 

[jira] [Deleted] (DRILL-4687) Not able query Sybase adaptive server from Apache drill

[Pritesh Maker (JIRA)]

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

Pritesh Maker deleted DRILL-4687:
-


> Not able query Sybase adaptive server from Apache drill
> ---
>
> Key: DRILL-4687
> URL: https://issues.apache.org/jira/browse/DRILL-4687
> Project: Apache Drill
>  Issue Type: Bug
>Reporter: Vikas Taank
>Priority: Major
>




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

[jira] [Resolved] (DRILL-4953) Please delete the JIRA DRILL-4687 as it violates confidentiality

[Pritesh Maker (JIRA)]

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

Pritesh Maker resolved DRILL-4953.
--
Resolution: Fixed
  Assignee: Pritesh Maker  (was: Parth Chandra)

> Please delete the JIRA DRILL-4687 as it violates confidentiality
> 
>
> Key: DRILL-4953
> URL: https://issues.apache.org/jira/browse/DRILL-4953
> Project: Apache Drill
>  Issue Type: Task
>  Components: Functions - Drill
>Reporter: Vikas Taank
>Assignee: Pritesh Maker
>Priority: Blocker
>
> Please delete the JIRA DRILL-4687 as it violates confidentiality
> https://issues.apache.org/jira/browse/DRILL-4687 



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

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

[Pritesh Maker (JIRA)]

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

Pritesh Maker reassigned DRILL-4897:


Assignee: Karthikeyan Manivannan  (was: Khurram Faraaz)

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



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

[jira] [Assigned] (DRILL-5786) A query that includes sort encounters Exception in RPC communication

[Pritesh Maker (JIRA)]

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

Pritesh Maker reassigned DRILL-5786:


Assignee: Karthikeyan Manivannan  (was: Paul Rogers)

> A query that includes sort encounters Exception in RPC communication
> 
>
> Key: DRILL-5786
> URL: https://issues.apache.org/jira/browse/DRILL-5786
> Project: Apache Drill
>  Issue Type: Bug
>  Components: Execution - Relational Operators
>Affects Versions: 1.11.0
>Reporter: Robert Hou
>Assignee: Karthikeyan Manivannan
>Priority: Major
> Fix For: 1.14.0
>
> Attachments: 2647d2b0-69bf-5a2b-0e23-81e8d49e464e.sys.drill, 
> drillbit.log
>
>
> Query is:
> {noformat}
> select count(*) from (select * from 
> dfs.`/drill/testdata/resource-manager/3500cols.tbl` order by 
> columns[450],columns[330],columns[230],columns[220],columns[110],columns[90],columns[80],columns[70],columns[40],columns[10],columns[20],columns[30],columns[40],columns[50],
>  
> columns[454],columns[413],columns[940],columns[834],columns[73],columns[140],columns[104],columns[],columns[30],columns[2420],columns[1520],
>  columns[1410], 
> columns[1110],columns[1290],columns[2380],columns[705],columns[45],columns[1054],columns[2430],columns[420],columns[404],columns[3350],
>  
> columns[],columns[153],columns[356],columns[84],columns[745],columns[1450],columns[103],columns[2065],columns[343],columns[3420],columns[530],
>  columns[3210] ) d where d.col433 = 'sjka skjf'
> {noformat}
> This is the same query as DRILL-5670 but no session variables are set.
> Here is the stack trace:
> {noformat}
> 2017-09-12 13:14:57,584 [BitServer-5] ERROR 
> o.a.d.exec.rpc.RpcExceptionHandler - Exception in RPC communication.  
> Connection: /10.10.100.190:31012 <--> /10.10.100.190:46230 (data server).  
> Closing connection.
> io.netty.handler.codec.DecoderException: 
> org.apache.drill.exec.exception.OutOfMemoryException: Failure allocating 
> buffer.
> at 
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:233)
>  ~[netty-codec-4.0.27.Final.jar:4.0.27.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:339)
>  [netty-transport-4.0.27.Final.jar:4.0.27.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:324)
>  [netty-transport-4.0.27.Final.jar:4.0.27.Final]
> at 
> io.netty.channel.ChannelInboundHandlerAdapter.channelRead(ChannelInboundHandlerAdapter.java:86)
>  [netty-transport-4.0.27.Final.jar:4.0.27.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:339)
>  [netty-transport-4.0.27.Final.jar:4.0.27.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:324)
>  [netty-transport-4.0.27.Final.jar:4.0.27.Final]
> at 
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:847)
>  [netty-transport-4.0.27.Final.jar:4.0.27.Final]
> at 
> io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:131)
>  [netty-transport-4.0.27.Final.jar:4.0.27.Final]
> at 
> io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:511) 
> [netty-transport-4.0.27.Final.jar:4.0.27.Final]
> at 
> io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:468)
>  [netty-transport-4.0.27.Final.jar:4.0.27.Final]
> at 
> io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:382) 
> [netty-transport-4.0.27.Final.jar:4.0.27.Final]
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:354) 
> [netty-transport-4.0.27.Final.jar:4.0.27.Final]
> at 
> io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:111)
>  [netty-common-4.0.27.Final.jar:4.0.27.Final]
> at java.lang.Thread.run(Thread.java:745) [na:1.7.0_111]
> Caused by: org.apache.drill.exec.exception.OutOfMemoryException: Failure 
> allocating buffer.
> at 
> io.netty.buffer.PooledByteBufAllocatorL.allocate(PooledByteBufAllocatorL.java:64)
>  ~[drill-memory-base-1.12.0-SNAPSHOT.jar:4.0.27.Final]
> at 
> org.apache.drill.exec.memory.AllocationManager.(AllocationManager.java:81)
>  ~[drill-memory-base-1.12.0-SNAPSHOT.jar:1.12.0-SNAPSHOT]
> at 
> org.apache.drill.exec.memory.BaseAllocator.bufferWithoutReservation(BaseAllocator.java:260)
>  ~[drill-memory-base-1.12.0-SNAPSHOT.jar:1.12.0-SNAPSHOT]
> at 
> org.apache.drill.exec.memory.BaseAllocator.buffer(BaseAllocator.java:243) 
> 

[jira] [Updated] (DRILL-5847) Flat Parquet Reader Performance Analysis

[Pritesh Maker (JIRA)]

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

Pritesh Maker updated DRILL-5847:
-
Fix Version/s: (was: 1.13.0)

> Flat Parquet Reader Performance Analysis
> 
>
> Key: DRILL-5847
> URL: https://issues.apache.org/jira/browse/DRILL-5847
> Project: Apache Drill
>  Issue Type: Sub-task
>  Components: Storage - Parquet
>Affects Versions: 1.11.0
>Reporter: salim achouche
>Assignee: salim achouche
>Priority: Major
>  Labels: performance
> Attachments: Drill Framework Enhancements.pdf, Flat Parquet Scanner 
> Enhancements Presentation.pdf
>
>
> This task is to analyze the Flat Parquet Reader logic looking for performance 
> improvements opportunities.



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

[jira] [Commented] (DRILL-6125) PartitionSenderRootExec can leak memory because close method is not synchronized

[ASF GitHub Bot (JIRA)]

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

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

Github user ilooner commented on the issue:

https://github.com/apache/drill/pull/1105
  
Nope never mind I think I spoke too soon. I just realized we may get 
multiple receivingFragmentFinished requests, one for each downstream receiver. 
Back to the drawing board.


> PartitionSenderRootExec can leak memory because close method is not 
> synchronized
> 
>
> Key: DRILL-6125
> URL: https://issues.apache.org/jira/browse/DRILL-6125
> Project: Apache Drill
>  Issue Type: Bug
>Affects Versions: 1.13.0
>Reporter: Timothy Farkas
>Assignee: Timothy Farkas
>Priority: Minor
> Fix For: 1.14.0
>
>
> PartitionSenderRootExec creates a PartitionerDecorator and saves it in the 
> *partitioner* field. The creation of the partitioner happens in the 
> createPartitioner method. This method get's called by the main fragment 
> thread. The partitioner field is accessed by the fragment thread during 
> normal execution but it can also be accessed by the receivingFragmentFinished 
> method which is a callback executed by the event processor thread. Because 
> multiple threads can access the partitioner field synchronization is done on 
> creation and on when receivingFragmentFinished. However, the close method can 
> also be called by the event processor thread, and the close method does not 
> synchronize before accessing the partitioner field. Since synchronization is 
> not done the event processor thread may have an old reference to the 
> partitioner when a query cancellation is done. Since it has an old reference 
> the current partitioner can may not be cleared and a memory leak may occur.



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

[jira] [Commented] (DRILL-6125) PartitionSenderRootExec can leak memory because close method is not synchronized

[ASF GitHub Bot (JIRA)]

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

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

Github user ilooner commented on the issue:

https://github.com/apache/drill/pull/1105
  
@arina-ielchiieva @vrozov In light of Vlad's comments I have reworked the 
synchronization model yet again. This change now removes all synchronization 
from PartitionSenderRootExec and enforces the guarantee that all the lifecycle 
methods of the PartitionSenderRootExec will only be called by a single Run 
thread in the FragmentExecutor. Also while making this change I discovered a 
few other bugs with how cancellations and receiver finishes are handled, so I 
have addressed those bugs as well. I will go into more detail about what I 
changed below.

# Motivation

As Vlad pointed out **close** and **innerNext** are never called 
concurrently. After closer inspection of the code I also released that 
currently (in apache master) innerNext and close will always be called by the 
**FragmentExecutor#run** thread. The only method of PartitionSenderRootExec 
that is not called by the **FragmentExecutor#run** thread is 
**receivingFragmentFinished**. In order to simplify the implementation of 
PartitionSenderRootExec and also simplify the design of the FragmentExecutor I 
changed the code so that only the **FragmentExecutor#run** thread calls 
**receivingFragmentFinished** as well. In this way we can remove all the 
synchronization from PartitionSenderRootExec. This was done by by:
 1. Making the event processor save the FragmentHandle in the event that a 
receiver finish request was sent. 
 2. After the **root.next()** loop terminates in **FragmentExecutor#run** 
the eventProcessor is checked to see if a finish request was received. If so 
**receivingFragmentFinished** is called on root by the **FragmentExecutor#run** 
method.

# Other Bugs

## Processing of multiple termination requests

The event processor would process all cancellation and finish requests, 
even if there is more than one. This doesn't really make sense, since we can 
only cancel or finish once. So I have changed the event processor to execute 
only the first termination request and ignore all the others.

## Simultaneous Cancellation and Finishing

Since the event processor would process multiple termination requests 
concurrently it was possible for a cancel and a finish message to be received 
and processed simultaneously. The results of this were not well defined since 
**close** and **receivingFragmentFinished** could be called concurrently.

# Other Improvements

Vlad also pointed out that we did not need the hasCloseoutThread atomic 
reference, since we were already using the myThreadRef atomic reference. That 
cleaned up the code a bit.


> PartitionSenderRootExec can leak memory because close method is not 
> synchronized
> 
>
> Key: DRILL-6125
> URL: https://issues.apache.org/jira/browse/DRILL-6125
> Project: Apache Drill
>  Issue Type: Bug
>Affects Versions: 1.13.0
>Reporter: Timothy Farkas
>Assignee: Timothy Farkas
>Priority: Minor
> Fix For: 1.14.0
>
>
> PartitionSenderRootExec creates a PartitionerDecorator and saves it in the 
> *partitioner* field. The creation of the partitioner happens in the 
> createPartitioner method. This method get's called by the main fragment 
> thread. The partitioner field is accessed by the fragment thread during 
> normal execution but it can also be accessed by the receivingFragmentFinished 
> method which is a callback executed by the event processor thread. Because 
> multiple threads can access the partitioner field synchronization is done on 
> creation and on when receivingFragmentFinished. However, the close method can 
> also be called by the event processor thread, and the close method does not 
> synchronize before accessing the partitioner field. Since synchronization is 
> not done the event processor thread may have an old reference to the 
> partitioner when a query cancellation is done. Since it has an old reference 
> the current partitioner can may not be cleared and a memory leak may occur.



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

[jira] [Updated] (DRILL-5239) Drill text reader reports wrong results when column value starts with '#'

[Kunal Khatua (JIRA)]

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

Kunal Khatua updated DRILL-5239:

Fix Version/s: Future

> Drill text reader reports wrong results when column value starts with '#'
> -
>
> Key: DRILL-5239
> URL: https://issues.apache.org/jira/browse/DRILL-5239
> Project: Apache Drill
>  Issue Type: Bug
>  Components: Storage - Text  CSV
>Affects Versions: 1.10.0
>Reporter: Rahul Challapalli
>Priority: Blocker
>  Labels: doc-impacting
> Fix For: Future
>
>
> git.commit.id.abbrev=2af709f
> Data Set :
> {code}
> D|32
> 8h|234
> ;#|3489
> ^$*(|308
> #|98
> {code}
> Wrong Result : (Last row is missing)
> {code}
> select columns[0] as col1, columns[1] as col2 from 
> dfs.`/drill/testdata/wtf2.tbl`;
> +---+---+
> | col1  | col2  |
> +---+---+
> | D | 32|
> | 8h| 234   |
> | ;#| 3489  |
> | ^$*(  | 308   |
> +---+---+
> 4 rows selected (0.233 seconds)
> {code}
> The issue does not however happen with a parquet file



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

[jira] [Commented] (DRILL-6216) Metadata mismatch when connecting to a Drill 1.12.0 with a Drill-1.13.0-SNAPSHOT driver

[Sorabh Hamirwasia (JIRA)]

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

Sorabh Hamirwasia commented on DRILL-6216:
--

Based on above analysis and discussion on Dev list ([1.13 - Release Blocker] - 
DRILL-6216: Metadata mismatch when connecting to a Drill 1.12.0 with a 
Drill-1.13.0-SNAPSHOT driver), we have decided to revert just the name change 
for 1.13 release.

> Metadata mismatch when connecting to a Drill 1.12.0 with a 
> Drill-1.13.0-SNAPSHOT driver
> ---
>
> Key: DRILL-6216
> URL: https://issues.apache.org/jira/browse/DRILL-6216
> Project: Apache Drill
>  Issue Type: Bug
>  Components: Client - JDBC
>Affects Versions: 1.13.0
>Reporter: Kunal Khatua
>Assignee: Sorabh Hamirwasia
>Priority: Blocker
> Fix For: 1.13.0
>
>
> When running against a 1.12.0 Drill server
> {code:sql}
>  select * from sys.`options`;
> {code}
> I hit the following issue in Squirrel-SQL client with the 1.13.0-SNAPSHOT 
> JDBC driver.
> {code:java}
> 2018-02-20 11:41:16,557 [Thread-2] DEBUG 
> net.sourceforge.squirrel_sql.fw.util.DefaultExceptionFormatter  - Error
> java.sql.SQLException: Unexpected RuntimeException: 
> java.lang.IllegalArgumentException: The field [`$values$` (BIGINT:OPTIONAL)] 
> doesn't match the provided metadata major_type {
>   minor_type: BIGINT
>   mode: OPTIONAL
> }
> name_part {
>   name: "num_val"
> }
> value_count: 153
> buffer_length: 1224
> .
>   at 
> org.apache.drill.jdbc.impl.DrillCursor.nextRowInternally(DrillCursor.java:544)
>   at 
> org.apache.drill.jdbc.impl.DrillCursor.loadInitialSchema(DrillCursor.java:602)
>   at 
> org.apache.drill.jdbc.impl.DrillResultSetImpl.execute(DrillResultSetImpl.java:1918)
>   at 
> org.apache.drill.jdbc.impl.DrillResultSetImpl.execute(DrillResultSetImpl.java:66)
>   at 
> oadd.org.apache.calcite.avatica.AvaticaConnection$1.execute(AvaticaConnection.java:630)
>   at 
> org.apache.drill.jdbc.impl.DrillMetaImpl.prepareAndExecute(DrillMetaImpl.java:1106)
>   at 
> org.apache.drill.jdbc.impl.DrillMetaImpl.prepareAndExecute(DrillMetaImpl.java:1117)
>   at 
> oadd.org.apache.calcite.avatica.AvaticaConnection.prepareAndExecuteInternal(AvaticaConnection.java:638)
>   at 
> org.apache.drill.jdbc.impl.DrillConnectionImpl.prepareAndExecuteInternal(DrillConnectionImpl.java:193)
>   at 
> oadd.org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:149)
>   at 
> oadd.org.apache.calcite.avatica.AvaticaStatement.execute(AvaticaStatement.java:209)
>   at 
> org.apache.drill.jdbc.impl.DrillStatementImpl.execute(DrillStatementImpl.java:101)
>   at 
> net.sourceforge.squirrel_sql.client.session.StatementWrapper.execute(StatementWrapper.java:165)
>   at 
> net.sourceforge.squirrel_sql.client.session.SQLExecuterTask.processQuery(SQLExecuterTask.java:378)
>   at 
> net.sourceforge.squirrel_sql.client.session.SQLExecuterTask.run(SQLExecuterTask.java:221)
>   at 
> net.sourceforge.squirrel_sql.fw.util.TaskExecuter.run(TaskExecuter.java:82)
>   at java.lang.Thread.run(Unknown Source)
> Caused by: java.lang.IllegalArgumentException: The field [`$values$` 
> (BIGINT:OPTIONAL)] doesn't match the provided metadata major_type {
>   minor_type: BIGINT
>   mode: OPTIONAL
> }
> name_part {
>   name: "num_val"
> }
> value_count: 153
> buffer_length: 1224
> .
>   at 
> oadd.com.google.common.base.Preconditions.checkArgument(Preconditions.java:145)
>   at 
> oadd.org.apache.drill.exec.vector.BigIntVector.load(BigIntVector.java:299)
>   at 
> oadd.org.apache.drill.exec.vector.NullableBigIntVector.load(NullableBigIntVector.java:295)
>   at 
> oadd.org.apache.drill.exec.record.RecordBatchLoader.load(RecordBatchLoader.java:135)
>   at 
> org.apache.drill.jdbc.impl.DrillCursor.nextRowInternally(DrillCursor.java:506)
>   ... 16 more
> {code}
> This issue however, doesn't exist when working with Apache Master 
> 1.13.0-SNAPSHOT



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

[jira] [Commented] (DRILL-6216) Metadata mismatch when connecting to a Drill 1.12.0 with a Drill-1.13.0-SNAPSHOT driver

[Sorabh Hamirwasia (JIRA)]

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

Sorabh Hamirwasia commented on DRILL-6216:
--

Hi All,

The root cause for DRILL-6216 is due to a recent change made as part 
of[https://urldefense.proofpoint.com/v2/url?u=https-3A__issues.apache.org_jira_browse_DRILL-2D6049=DwIFAw=cskdkSMqhcnjZxdQVpwTXg=gRpEl0WzXE3EMrwj0KFbZXGXRyadOthF2jlYxvhTlQg=YvCUBRsPY3EVX3oqGKDhUhKNuvrmpt37EuaRNYLIxlE=oeEFw22PxBEEd6WyfpzeD5v-oi_PsD2SaoR1SDO-RKw=].
 With this PR a default field name for values ValueVector inside any 
NullableValueVector was introduced which is $values$ [1]. Before this PR the 
values ValueVector field name was same as the field name of actual 
NullableValueVector holding it [2]. In the load method of certain ValueVectors 
like BigIntVector there is an equality check for the ValueVector field name and 
metadata.name_part name [3].

In setup where Drillbit and DrillClient are running in different version 
(between 1.12 and 1.13) the equality check in load method will fail. For 
example: When server is running 1.13 and client is on 1.12, in that case the 
record batch from server side will come with NullableValueVector (NV1 with 
field name as num_val) but with it's values ValueVector field name as $values$. 
When on client side corresponding NullableValueVector (NV2) is created it will 
use the actual field name (num_val) for values ValueVector. After calling load 
on received NullableValueVector NV2 with metadata information from server that 
internally alls load on values ValueVector and the check fails since ($values$ 
!= num_val).


Since the change is in template of ValueVector, to fix this issue both client 
and server needs to identify their respective version on which they are running 
and choose the field name for values ValueVector correspondingly. Given 
DRILL-6049 touches huge sets of files I am also not sure what are the other 
impacts with it. It would be great to discuss on how we should proceed with 
this issue before making any further change.


[1]: 
[https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_apache_drill_blob_master_exec_vector_src_main_java_org_apache_drill_exec_vector_ValueVector.java-23L92=DwIFAw=cskdkSMqhcnjZxdQVpwTXg=gRpEl0WzXE3EMrwj0KFbZXGXRyadOthF2jlYxvhTlQg=YvCUBRsPY3EVX3oqGKDhUhKNuvrmpt37EuaRNYLIxlE=gjEcDbuGniihjh_1RdQEpGJ9eboKsgPPTJkH8_OCytU=]

[https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_apache_drill_blob_master_exec_vector_src_main_codegen_templates_NullableValueVectors.java-23L82=DwIFAw=cskdkSMqhcnjZxdQVpwTXg=gRpEl0WzXE3EMrwj0KFbZXGXRyadOthF2jlYxvhTlQg=YvCUBRsPY3EVX3oqGKDhUhKNuvrmpt37EuaRNYLIxlE=miSD59RRvY6njdKTyLSf5q8U4S51NcxY3IulJGonSxw=]

[2]:https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_apache_drill_blob_1.12.0_exec_vector_src_main_codegen_templates_NullableValueVectors.java-23L70=DwIFAw=cskdkSMqhcnjZxdQVpwTXg=gRpEl0WzXE3EMrwj0KFbZXGXRyadOthF2jlYxvhTlQg=YvCUBRsPY3EVX3oqGKDhUhKNuvrmpt37EuaRNYLIxlE=3VokpAZoZGSvcdfIU23QuigGGKHPPupiCcLpxDxeP84=

[3]: 
[https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_apache_drill_blob_1.12.0_exec_vector_src_main_codegen_templates_FixedValueVectors.java-23L238=DwIFAw=cskdkSMqhcnjZxdQVpwTXg=gRpEl0WzXE3EMrwj0KFbZXGXRyadOthF2jlYxvhTlQg=YvCUBRsPY3EVX3oqGKDhUhKNuvrmpt37EuaRNYLIxlE=-UDZrABPkMkRiAURufI-oT2AepfOHC9d5v-OXH64sHo=]

> Metadata mismatch when connecting to a Drill 1.12.0 with a 
> Drill-1.13.0-SNAPSHOT driver
> ---
>
> Key: DRILL-6216
> URL: https://issues.apache.org/jira/browse/DRILL-6216
> Project: Apache Drill
>  Issue Type: Bug
>  Components: Client - JDBC
>Affects Versions: 1.13.0
>Reporter: Kunal Khatua
>Assignee: Sorabh Hamirwasia
>Priority: Blocker
> Fix For: 1.13.0
>
>
> When running against a 1.12.0 Drill server
> {code:sql}
>  select * from sys.`options`;
> {code}
> I hit the following issue in Squirrel-SQL client with the 1.13.0-SNAPSHOT 
> JDBC driver.
> {code:java}
> 2018-02-20 11:41:16,557 [Thread-2] DEBUG 
> net.sourceforge.squirrel_sql.fw.util.DefaultExceptionFormatter  - Error
> java.sql.SQLException: Unexpected RuntimeException: 
> java.lang.IllegalArgumentException: The field [`$values$` (BIGINT:OPTIONAL)] 
> doesn't match the provided metadata major_type {
>   minor_type: BIGINT
>   mode: OPTIONAL
> }
> name_part {
>   name: "num_val"
> }
> value_count: 153
> buffer_length: 1224
> .
>   at 
> org.apache.drill.jdbc.impl.DrillCursor.nextRowInternally(DrillCursor.java:544)
>   at 
> org.apache.drill.jdbc.impl.DrillCursor.loadInitialSchema(DrillCursor.java:602)
>   at 
> org.apache.drill.jdbc.impl.DrillResultSetImpl.execute(DrillResultSetImpl.java:1918)
>   at 
> 

[jira] [Updated] (DRILL-6192) Drill is vulnerable to CVE-2017-12197

[Pritesh Maker (JIRA)]

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

Pritesh Maker updated DRILL-6192:
-
Reviewer: Arina Ielchiieva

> Drill is vulnerable to CVE-2017-12197
> -
>
> Key: DRILL-6192
> URL: https://issues.apache.org/jira/browse/DRILL-6192
> Project: Apache Drill
>  Issue Type: Bug
>Reporter: Volodymyr Tkach
>Assignee: Volodymyr Tkach
>Priority: Major
>
> The current version of libpam4j bundled with MCS does not perform any 
> authorization check. Any user with valid password could access the cluster 
> even if the user account is disabled/password expired/'not allowed to access 
> the service(pam_access ..)' etc..



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

[jira] [Assigned] (DRILL-6219) Filter pushdown doesn't work with star operator if there is a subquery with it's own filter

[Pritesh Maker (JIRA)]

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

Pritesh Maker reassigned DRILL-6219:


Assignee: Arina Ielchiieva

> Filter pushdown doesn't work with star operator if there is a subquery with 
> it's own filter
> ---
>
> Key: DRILL-6219
> URL: https://issues.apache.org/jira/browse/DRILL-6219
> Project: Apache Drill
>  Issue Type: Bug
>Affects Versions: 1.13.0
>Reporter: Anton Gozhiy
>Assignee: Arina Ielchiieva
>Priority: Major
> 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}
> select * from (select * from 
> dfs.drillTestDir.`DRILL_6118_parquet_partitioned_by_folders` where c1>2) 
> where c1>3{code}
> *Expected result:*
> Filrers "c1>3" and "c1>2" should both be pushed down so only the data from 
> the folder "d3" should be scanned.
> *Actual result:* 
> The data from the folders "d1" and  "d3" are being scanned so as only filter 
> "c1>2" is pushed down
> *Physical plan:*
> {noformat}
> 00-00Screen : rowType = RecordType(DYNAMIC_STAR **): rowcount = 10.0, 
> cumulative cost = {201.0 rows, 581.0 cpu, 0.0 io, 0.0 network, 0.0 memory}, 
> id = 105545
> 00-01  Project(**=[$0]) : rowType = RecordType(DYNAMIC_STAR **): rowcount 
> = 10.0, cumulative cost = {200.0 rows, 580.0 cpu, 0.0 io, 0.0 network, 0.0 
> memory}, id = 105544
> 00-02SelectionVectorRemover : rowType = RecordType(DYNAMIC_STAR 
> T25¦¦**): rowcount = 10.0, cumulative cost = {190.0 rows, 570.0 cpu, 0.0 io, 
> 0.0 network, 0.0 memory}, id = 105543
> 00-03  Filter(condition=[>(ITEM($0, 'c1'), 3)]) : rowType = 
> RecordType(DYNAMIC_STAR T25¦¦**): rowcount = 10.0, cumulative cost = {180.0 
> rows, 560.0 cpu, 0.0 io, 0.0 network, 0.0 memory}, id = 105542
> 00-04Project(T25¦¦**=[$0]) : rowType = RecordType(DYNAMIC_STAR 
> T25¦¦**): rowcount = 20.0, cumulative cost = {160.0 rows, 440.0 cpu, 0.0 io, 
> 0.0 network, 0.0 memory}, id = 105541
> 00-05  SelectionVectorRemover : rowType = RecordType(DYNAMIC_STAR 
> T25¦¦**, ANY c1): rowcount = 20.0, cumulative cost = {140.0 rows, 420.0 cpu, 
> 0.0 io, 0.0 network, 0.0 memory}, id = 105540
> 00-06Filter(condition=[>($1, 2)]) : rowType = 
> RecordType(DYNAMIC_STAR T25¦¦**, ANY c1): rowcount = 20.0, cumulative cost = 
> {120.0 rows, 400.0 cpu, 0.0 io, 0.0 network, 0.0 memory}, id = 105539
> 00-07  Project(T25¦¦**=[$0], c1=[$1]) : rowType = 
> RecordType(DYNAMIC_STAR T25¦¦**, ANY c1): rowcount = 40.0, cumulative cost = 
> {80.0 rows, 160.0 cpu, 0.0 io, 0.0 network, 0.0 memory}, id = 105538
> 00-08Scan(groupscan=[ParquetGroupScan 
> [entries=[ReadEntryWithPath 
> [path=/drill/testdata/DRILL_6118_parquet_partitioned_by_folders/d1/0_0_0.parquet],
>  ReadEntryWithPath 
> [path=/drill/testdata/DRILL_6118_parquet_partitioned_by_folders/d3/0_0_0.parquet]],
>  
> selectionRoot=maprfs:/drill/testdata/DRILL_6118_parquet_partitioned_by_folders,
>  numFiles=2, numRowGroups=2, usedMetadataFile=false, columns=[`**`]]]) : 
> rowType = RecordType(DYNAMIC_STAR **, ANY c1): rowcount = 40.0, cumulative 
> cost = {40.0 rows, 80.0 cpu, 0.0 io, 0.0 network, 0.0 memory}, id = 105537
> {noformat}
> *Note:* Works fine if select column names instead of "*"



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

[jira] [Assigned] (DRILL-4547) Javadoc fails with Java8

[Venkata Jyothsna Donapati (JIRA)]

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

Venkata Jyothsna Donapati reassigned DRILL-4547:


Assignee: Venkata Jyothsna Donapati

> Javadoc fails with Java8
> 
>
> Key: DRILL-4547
> URL: https://issues.apache.org/jira/browse/DRILL-4547
> Project: Apache Drill
>  Issue Type: Bug
>  Components: Tools, Build  Test
>Affects Versions: 1.6.0
>Reporter: Laurent Goujon
>Assignee: Venkata Jyothsna Donapati
>Priority: Major
>
> Javadoc cannot be generated when using Java8 (likely because the parser is 
> now more strict).
> Here's an example of issues when trying to generate javadocs in module 
> {{drill-fmpp-maven-plugin}}
> {noformat}
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-javadoc-plugin:2.9.1:jar (attach-javadocs) on 
> project drill-fmpp-maven-plugin: MavenReportException: Error while creating 
> archive:
> [ERROR] Exit code: 1 - 
> /Users/laurent/devel/drill/tools/fmpp/src/main/java/org/apache/drill/fmpp/mojo/FMPPMojo.java:44:
>  error: unknown tag: goal
> [ERROR] * @goal generate
> [ERROR] ^
> [ERROR] 
> /Users/laurent/devel/drill/tools/fmpp/src/main/java/org/apache/drill/fmpp/mojo/FMPPMojo.java:45:
>  error: unknown tag: phase
> [ERROR] * @phase generate-sources
> [ERROR] ^
> [ERROR] 
> /Users/laurent/devel/drill/tools/fmpp/target/generated-sources/plugin/org/apache/drill/fmpp/mojo/HelpMojo.java:25:
>  error: unknown tag: goal
> [ERROR] * @goal help
> [ERROR] ^
> [ERROR] 
> /Users/laurent/devel/drill/tools/fmpp/target/generated-sources/plugin/org/apache/drill/fmpp/mojo/HelpMojo.java:26:
>  error: unknown tag: requiresProject
> [ERROR] * @requiresProject false
> [ERROR] ^
> [ERROR] 
> /Users/laurent/devel/drill/tools/fmpp/target/generated-sources/plugin/org/apache/drill/fmpp/mojo/HelpMojo.java:27:
>  error: unknown tag: threadSafe
> [ERROR] * @threadSafe
> [ERROR] ^
> [ERROR] 
> [ERROR] Command line was: 
> /Library/Java/JavaVirtualMachines/jdk1.8.0_72.jdk/Contents/Home/bin/javadoc 
> @options @packages
> [ERROR] 
> [ERROR] Refer to the generated Javadoc files in 
> '/Users/laurent/devel/drill/tools/fmpp/target/apidocs' dir.
> [ERROR] -> [Help 1]
> [ERROR] 
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR] 
> [ERROR] For more information about the errors and possible solutions, please 
> read the following articles:
> [ERROR] [Help 1] 
> http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
> [ERROR] 
> [ERROR] After correcting the problems, you can resume the build with the 
> command
> [ERROR]   mvn  -rf :drill-fmpp-maven-plugin
> {noformat}



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

[jira] [Updated] (DRILL-6219) Filter pushdown doesn't work with star operator if there is a subquery with it's own filter

[Anton Gozhiy (JIRA)]

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

Anton Gozhiy updated DRILL-6219:

Attachment: DRILL_6118_data_source.csv

> Filter pushdown doesn't work with star operator if there is a subquery with 
> it's own filter
> ---
>
> Key: DRILL-6219
> URL: https://issues.apache.org/jira/browse/DRILL-6219
> Project: Apache Drill
>  Issue Type: Bug
>Affects Versions: 1.13.0
>Reporter: Anton Gozhiy
>Priority: Major
> 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}
> select * from (select * from 
> dfs.drillTestDir.`DRILL_6118_parquet_partitioned_by_folders` where c1>2) 
> where c1>3{code}
> *Expected result:*
> Filrers "c1>3" and "c1>2" should both be pushed down so only the data from 
> the folder "d3" should be scanned.
> *Actual result:* 
> The data from the folders "d1" and  "d3" are being scanned so as only filter 
> "c1>2" is pushed down
> *Physical plan:*
> {noformat}
> 00-00Screen : rowType = RecordType(DYNAMIC_STAR **): rowcount = 10.0, 
> cumulative cost = {201.0 rows, 581.0 cpu, 0.0 io, 0.0 network, 0.0 memory}, 
> id = 105545
> 00-01  Project(**=[$0]) : rowType = RecordType(DYNAMIC_STAR **): rowcount 
> = 10.0, cumulative cost = {200.0 rows, 580.0 cpu, 0.0 io, 0.0 network, 0.0 
> memory}, id = 105544
> 00-02SelectionVectorRemover : rowType = RecordType(DYNAMIC_STAR 
> T25¦¦**): rowcount = 10.0, cumulative cost = {190.0 rows, 570.0 cpu, 0.0 io, 
> 0.0 network, 0.0 memory}, id = 105543
> 00-03  Filter(condition=[>(ITEM($0, 'c1'), 3)]) : rowType = 
> RecordType(DYNAMIC_STAR T25¦¦**): rowcount = 10.0, cumulative cost = {180.0 
> rows, 560.0 cpu, 0.0 io, 0.0 network, 0.0 memory}, id = 105542
> 00-04Project(T25¦¦**=[$0]) : rowType = RecordType(DYNAMIC_STAR 
> T25¦¦**): rowcount = 20.0, cumulative cost = {160.0 rows, 440.0 cpu, 0.0 io, 
> 0.0 network, 0.0 memory}, id = 105541
> 00-05  SelectionVectorRemover : rowType = RecordType(DYNAMIC_STAR 
> T25¦¦**, ANY c1): rowcount = 20.0, cumulative cost = {140.0 rows, 420.0 cpu, 
> 0.0 io, 0.0 network, 0.0 memory}, id = 105540
> 00-06Filter(condition=[>($1, 2)]) : rowType = 
> RecordType(DYNAMIC_STAR T25¦¦**, ANY c1): rowcount = 20.0, cumulative cost = 
> {120.0 rows, 400.0 cpu, 0.0 io, 0.0 network, 0.0 memory}, id = 105539
> 00-07  Project(T25¦¦**=[$0], c1=[$1]) : rowType = 
> RecordType(DYNAMIC_STAR T25¦¦**, ANY c1): rowcount = 40.0, cumulative cost = 
> {80.0 rows, 160.0 cpu, 0.0 io, 0.0 network, 0.0 memory}, id = 105538
> 00-08Scan(groupscan=[ParquetGroupScan 
> [entries=[ReadEntryWithPath 
> [path=/drill/testdata/DRILL_6118_parquet_partitioned_by_folders/d1/0_0_0.parquet],
>  ReadEntryWithPath 
> [path=/drill/testdata/DRILL_6118_parquet_partitioned_by_folders/d3/0_0_0.parquet]],
>  
> selectionRoot=maprfs:/drill/testdata/DRILL_6118_parquet_partitioned_by_folders,
>  numFiles=2, numRowGroups=2, usedMetadataFile=false, columns=[`**`]]]) : 
> rowType = RecordType(DYNAMIC_STAR **, ANY c1): rowcount = 40.0, cumulative 
> cost = {40.0 rows, 80.0 cpu, 0.0 io, 0.0 network, 0.0 memory}, id = 105537
> {noformat}
> *Note:* Works fine if select column names instead of "*"



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

[jira] [Updated] (DRILL-6219) Filter pushdown doesn't work with star operator if there is a subquery with it's own filter

[Anton Gozhiy (JIRA)]

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

Anton Gozhiy updated DRILL-6219:

Description: 
*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}
select * from (select * from 
dfs.drillTestDir.`DRILL_6118_parquet_partitioned_by_folders` where c1>2) where 
c1>3{code}

*Expected result:*
Filrers "c1>3" and "c1>2" should both be pushed down so only the data from the 
folder "d3" should be scanned.

*Actual result:* 
The data from the folders "d1" and  "d3" are being scanned so as only filter 
"c1>2" is pushed down

*Physical plan:*
{noformat}
00-00Screen : rowType = RecordType(DYNAMIC_STAR **): rowcount = 10.0, 
cumulative cost = {201.0 rows, 581.0 cpu, 0.0 io, 0.0 network, 0.0 memory}, id 
= 105545
00-01  Project(**=[$0]) : rowType = RecordType(DYNAMIC_STAR **): rowcount = 
10.0, cumulative cost = {200.0 rows, 580.0 cpu, 0.0 io, 0.0 network, 0.0 
memory}, id = 105544
00-02SelectionVectorRemover : rowType = RecordType(DYNAMIC_STAR 
T25¦¦**): rowcount = 10.0, cumulative cost = {190.0 rows, 570.0 cpu, 0.0 io, 
0.0 network, 0.0 memory}, id = 105543
00-03  Filter(condition=[>(ITEM($0, 'c1'), 3)]) : rowType = 
RecordType(DYNAMIC_STAR T25¦¦**): rowcount = 10.0, cumulative cost = {180.0 
rows, 560.0 cpu, 0.0 io, 0.0 network, 0.0 memory}, id = 105542
00-04Project(T25¦¦**=[$0]) : rowType = RecordType(DYNAMIC_STAR 
T25¦¦**): rowcount = 20.0, cumulative cost = {160.0 rows, 440.0 cpu, 0.0 io, 
0.0 network, 0.0 memory}, id = 105541
00-05  SelectionVectorRemover : rowType = RecordType(DYNAMIC_STAR 
T25¦¦**, ANY c1): rowcount = 20.0, cumulative cost = {140.0 rows, 420.0 cpu, 
0.0 io, 0.0 network, 0.0 memory}, id = 105540
00-06Filter(condition=[>($1, 2)]) : rowType = 
RecordType(DYNAMIC_STAR T25¦¦**, ANY c1): rowcount = 20.0, cumulative cost = 
{120.0 rows, 400.0 cpu, 0.0 io, 0.0 network, 0.0 memory}, id = 105539
00-07  Project(T25¦¦**=[$0], c1=[$1]) : rowType = 
RecordType(DYNAMIC_STAR T25¦¦**, ANY c1): rowcount = 40.0, cumulative cost = 
{80.0 rows, 160.0 cpu, 0.0 io, 0.0 network, 0.0 memory}, id = 105538
00-08Scan(groupscan=[ParquetGroupScan 
[entries=[ReadEntryWithPath 
[path=/drill/testdata/DRILL_6118_parquet_partitioned_by_folders/d1/0_0_0.parquet],
 ReadEntryWithPath 
[path=/drill/testdata/DRILL_6118_parquet_partitioned_by_folders/d3/0_0_0.parquet]],
 
selectionRoot=maprfs:/drill/testdata/DRILL_6118_parquet_partitioned_by_folders, 
numFiles=2, numRowGroups=2, usedMetadataFile=false, columns=[`**`]]]) : rowType 
= RecordType(DYNAMIC_STAR **, ANY c1): rowcount = 40.0, cumulative cost = {40.0 
rows, 80.0 cpu, 0.0 io, 0.0 network, 0.0 memory}, id = 105537
{noformat}

*Note:* Works fine if select column names instead of "*"

  was:
*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}
select * from (select * from 
dfs.drillTestDir.`DRILL_6118_parquet_partitioned_by_folders` where c1>2) where 
c1>3{code}

*Expected result:*
Filrers "c1>3" and "c1>2" should both be pushed down so only the data from the 
folder "d3" should be scanned.

*Actual result:* 
The data from the 

[jira] [Updated] (DRILL-6219) Filter pushdown doesn't work with star operator if there is a subquery with it's own filter

[Anton Gozhiy (JIRA)]

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

Anton Gozhiy updated DRILL-6219:

Description: 
*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}
select * from (select * from 
dfs.drillTestDir.`DRILL_6118_parquet_partitioned_by_folders` where c1>2) where 
c1>3{code}

*Expected result:*
Filrers "c1>3" and "c1>2" should both be pushed down so only the data from the 
folder "d3" should be scanned.

*Actual result:* 
The data from the folders "d1" and  "d3" are being scanned so as only filter 
"c1>2" is pushed down

*Physical plan:*
{noformat}
00-00Screen : rowType = RecordType(DYNAMIC_STAR **): rowcount = 10.0, 
cumulative cost = {201.0 rows, 581.0 cpu, 0.0 io, 0.0 network, 0.0 memory}, id 
= 105545
00-01  Project(**=[$0]) : rowType = RecordType(DYNAMIC_STAR **): rowcount = 
10.0, cumulative cost = {200.0 rows, 580.0 cpu, 0.0 io, 0.0 network, 0.0 
memory}, id = 105544
00-02SelectionVectorRemover : rowType = RecordType(DYNAMIC_STAR 
T25¦¦**): rowcount = 10.0, cumulative cost = {190.0 rows, 570.0 cpu, 0.0 io, 
0.0 network, 0.0 memory}, id = 105543
00-03  Filter(condition=[>(ITEM($0, 'c1'), 3)]) : rowType = 
RecordType(DYNAMIC_STAR T25¦¦**): rowcount = 10.0, cumulative cost = {180.0 
rows, 560.0 cpu, 0.0 io, 0.0 network, 0.0 memory}, id = 105542
00-04Project(T25¦¦**=[$0]) : rowType = RecordType(DYNAMIC_STAR 
T25¦¦**): rowcount = 20.0, cumulative cost = {160.0 rows, 440.0 cpu, 0.0 io, 
0.0 network, 0.0 memory}, id = 105541
00-05  SelectionVectorRemover : rowType = RecordType(DYNAMIC_STAR 
T25¦¦**, ANY c1): rowcount = 20.0, cumulative cost = {140.0 rows, 420.0 cpu, 
0.0 io, 0.0 network, 0.0 memory}, id = 105540
00-06Filter(condition=[>($1, 2)]) : rowType = 
RecordType(DYNAMIC_STAR T25¦¦**, ANY c1): rowcount = 20.0, cumulative cost = 
{120.0 rows, 400.0 cpu, 0.0 io, 0.0 network, 0.0 memory}, id = 105539
00-07  Project(T25¦¦**=[$0], c1=[$1]) : rowType = 
RecordType(DYNAMIC_STAR T25¦¦**, ANY c1): rowcount = 40.0, cumulative cost = 
{80.0 rows, 160.0 cpu, 0.0 io, 0.0 network, 0.0 memory}, id = 105538
00-08Scan(groupscan=[ParquetGroupScan 
[entries=[ReadEntryWithPath 
[path=/drill/testdata/DRILL_6118_parquet_partitioned_by_folders/d1/0_0_0.parquet],
 ReadEntryWithPath 
[path=/drill/testdata/DRILL_6118_parquet_partitioned_by_folders/d3/0_0_0.parquet]],
 
selectionRoot=maprfs:/drill/testdata/DRILL_6118_parquet_partitioned_by_folders, 
numFiles=2, numRowGroups=2, usedMetadataFile=false, columns=[`**`]]]) : rowType 
= RecordType(DYNAMIC_STAR **, ANY c1): rowcount = 40.0, cumulative cost = {40.0 
rows, 80.0 cpu, 0.0 io, 0.0 network, 0.0 memory}, id = 105537
{noformat}


  was:
*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}
select * from (select * from 
dfs.drillTestDir.`DRILL_6118_parquet_partitioned_by_folders` where c1>2) where 
c1>3{code}

*Expected result:*
Filrers "c1>3" and "c1>2" should both be pushed down so only the data from the 
folder "d3" should be scanned.

*Actual result:* 
The data from the folders "d1" and  "d3" are being scanned so as only filter 

[jira] [Created] (DRILL-6219) Filter pushdown doesn't work with star operator if there is a subquery with it's own filter

[Anton Gozhiy (JIRA)]

Anton Gozhiy created DRILL-6219:
---

 Summary: Filter pushdown doesn't work with star operator if there 
is a subquery with it's own filter
 Key: DRILL-6219
 URL: https://issues.apache.org/jira/browse/DRILL-6219
 Project: Apache Drill
  Issue Type: Bug
Affects Versions: 1.13.0
Reporter: Anton Gozhiy


*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}
select * from (select * from 
dfs.drillTestDir.`DRILL_6118_parquet_partitioned_by_folders` where c1>2) where 
c1>3{code}

*Expected result:*
Filrers "c1>3" and "c1>2" should both be pushed down so only the data from the 
folder "d3" should be scanned.

*Actual result:* 
The data from the folders "d1" and  "d3" are being scanned so as only filter 
"c1>2" is pushed down

*Physical plan:*
{code}
00-00Screen : rowType = RecordType(DYNAMIC_STAR **): rowcount = 10.0, 
cumulative cost = {201.0 rows, 581.0 cpu, 0.0 io, 0.0 network, 0.0 memory}, id 
= 105545
00-01  Project(**=[$0]) : rowType = RecordType(DYNAMIC_STAR **): rowcount = 
10.0, cumulative cost = {200.0 rows, 580.0 cpu, 0.0 io, 0.0 network, 0.0 
memory}, id = 105544
00-02SelectionVectorRemover : rowType = RecordType(DYNAMIC_STAR 
T25¦¦**): rowcount = 10.0, cumulative cost = {190.0 rows, 570.0 cpu, 0.0 io, 
0.0 network, 0.0 memory}, id = 105543
00-03  Filter(condition=[>(ITEM($0, 'c1'), 3)]) : rowType = 
RecordType(DYNAMIC_STAR T25¦¦**): rowcount = 10.0, cumulative cost = {180.0 
rows, 560.0 cpu, 0.0 io, 0.0 network, 0.0 memory}, id = 105542
00-04Project(T25¦¦**=[$0]) : rowType = RecordType(DYNAMIC_STAR 
T25¦¦**): rowcount = 20.0, cumulative cost = {160.0 rows, 440.0 cpu, 0.0 io, 
0.0 network, 0.0 memory}, id = 105541
00-05  SelectionVectorRemover : rowType = RecordType(DYNAMIC_STAR 
T25¦¦**, ANY c1): rowcount = 20.0, cumulative cost = {140.0 rows, 420.0 cpu, 
0.0 io, 0.0 network, 0.0 memory}, id = 105540
00-06Filter(condition=[>($1, 2)]) : rowType = 
RecordType(DYNAMIC_STAR T25¦¦**, ANY c1): rowcount = 20.0, cumulative cost = 
{120.0 rows, 400.0 cpu, 0.0 io, 0.0 network, 0.0 memory}, id = 105539
00-07  Project(T25¦¦**=[$0], c1=[$1]) : rowType = 
RecordType(DYNAMIC_STAR T25¦¦**, ANY c1): rowcount = 40.0, cumulative cost = 
{80.0 rows, 160.0 cpu, 0.0 io, 0.0 network, 0.0 memory}, id = 105538
00-08Scan(groupscan=[ParquetGroupScan 
[entries=[ReadEntryWithPath 
[path=/drill/testdata/DRILL_6118_parquet_partitioned_by_folders/d1/0_0_0.parquet],
 ReadEntryWithPath 
[path=/drill/testdata/DRILL_6118_parquet_partitioned_by_folders/d3/0_0_0.parquet]],
 
selectionRoot=maprfs:/drill/testdata/DRILL_6118_parquet_partitioned_by_folders, 
numFiles=2, numRowGroups=2, usedMetadataFile=false, columns=[`**`]]]) : rowType 
= RecordType(DYNAMIC_STAR **, ANY c1): rowcount = 40.0, cumulative cost = {40.0 
rows, 80.0 cpu, 0.0 io, 0.0 network, 0.0 memory}, id = 105537
{code}




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

[jira] [Updated] (DRILL-6145) Implement Hive MapR-DB JSON handler.

[Vitalii Diravka (JIRA)]

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

Vitalii Diravka updated DRILL-6145:
---
Description: 
Similar to "hive-hbase-storage-handler" to support querying MapR-DB Hive's 
external tables it is necessary to add "hive-maprdb-json-handler".

Use case:

 # Create a table MapR-DB JSON table:
{code}
_> mapr dbshell_

_maprdb root:> create /tmp/table/json_  (make sure /tmp/table exists)
{code}
-- insert data
{code}
insert /tmp/table/json --value '\{"_id":"movie002" , "title":"Developers on 
the Edge", "studio":"Command Line Studios"}'

insert /tmp/table/json --id movie003 --value '\{"title":"The Golden 
Master", "studio":"All-Nighter"}'

{code} 
 #  Create a Hive external table:
{code}
hive> CREATE EXTERNAL TABLE mapr_db_json_hive_tbl ( 
> movie_id string, title string, studio string) 
> STORED BY 'org.apache.hadoop.hive.maprdb.json.MapRDBJsonStorageHandler' 
> TBLPROPERTIES("maprdb.table.name" = "/tmp/table/json","maprdb.column.id" 
= "movie_id");
{code}
 
 #  Use hive schema to query this table via Drill:
{code}
0: jdbc:drill:> select * from hive.mapr_db_json_hive_tbl;
{code}

  was:
Similar to "hive-hbase-storage-handler" to support querying MapR-DB Hive's 
external tables it is necessary to add "hive-maprdb-json-handler".

Use case:

 # Create a table MapR-DB JSON table:
{code}
_> mapr dbshell_

_maprdb root:> create /tmp/table/json_  (make sure /tmp/table exists)
{code}
-- insert data
{code}
insert /tmp/table/json --value '\{"_id":"movie002" , "title":"Developers on 
the Edge", "studio":"Command Line Studios"}'

insert /tmp/table/json --id movie003 --value '\{"title":"The Golden 
Master", "studio":"All-Nighter"}'

{code} 
 #  Create a Hive external table:
{code}
CREATE EXTERNAL TABLE mapr_db_json_hive_tbl ( 
movie_id string, title string, studio string) 
STORED BY 'org.apache.hadoop.hive.maprdb.json.MapRDBJsonStorageHandler' 
TBLPROPERTIES("maprdb.table.name" = "/tmp/table/json","maprdb.column.id" = 
"movie_id");
{code}
 
 #  Use hive schema to query this table:
{code}
select * from hive.mapr_db_json_hive_tbl;
{code}


> Implement Hive MapR-DB JSON handler. 
> -
>
> Key: DRILL-6145
> URL: https://issues.apache.org/jira/browse/DRILL-6145
> Project: Apache Drill
>  Issue Type: Bug
>  Components: Storage - Hive, Storage - MapRDB
>Affects Versions: 1.12.0
>Reporter: Vitalii Diravka
>Assignee: Vitalii Diravka
>Priority: Major
>  Labels: doc-impacting
> Fix For: 1.14.0
>
>
> Similar to "hive-hbase-storage-handler" to support querying MapR-DB Hive's 
> external tables it is necessary to add "hive-maprdb-json-handler".
> Use case:
>  # Create a table MapR-DB JSON table:
> {code}
> _> mapr dbshell_
> _maprdb root:> create /tmp/table/json_  (make sure /tmp/table exists)
> {code}
> -- insert data
> {code}
> insert /tmp/table/json --value '\{"_id":"movie002" , "title":"Developers 
> on the Edge", "studio":"Command Line Studios"}'
> insert /tmp/table/json --id movie003 --value '\{"title":"The Golden 
> Master", "studio":"All-Nighter"}'
> {code} 
>  #  Create a Hive external table:
> {code}
> hive> CREATE EXTERNAL TABLE mapr_db_json_hive_tbl ( 
> > movie_id string, title string, studio string) 
> > STORED BY 'org.apache.hadoop.hive.maprdb.json.MapRDBJsonStorageHandler' 
> > TBLPROPERTIES("maprdb.table.name" = 
> "/tmp/table/json","maprdb.column.id" = "movie_id");
> {code}
>  
>  #  Use hive schema to query this table via Drill:
> {code}
> 0: jdbc:drill:> select * from hive.mapr_db_json_hive_tbl;
> {code}



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

[jira] [Commented] (DRILL-6218) Update release profile to not generate MD5 checksum

[ASF GitHub Bot (JIRA)]

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

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

Github user asfgit closed the pull request at:

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


> Update release profile to not generate MD5 checksum
> ---
>
> Key: DRILL-6218
> URL: https://issues.apache.org/jira/browse/DRILL-6218
> Project: Apache Drill
>  Issue Type: Task
>Affects Versions: 1.12.0
>Reporter: Parth Chandra
>Assignee: Parth Chandra
>Priority: Major
>  Labels: ready-to-commit
> Fix For: 1.13.0
>
>
> Latest release guidelines require that we not generate a MD5 checksum.



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

[jira] [Updated] (DRILL-6145) Implement Hive MapR-DB JSON handler.

[Vitalii Diravka (JIRA)]

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

Vitalii Diravka updated DRILL-6145:
---
Priority: Major  (was: Critical)

> Implement Hive MapR-DB JSON handler. 
> -
>
> Key: DRILL-6145
> URL: https://issues.apache.org/jira/browse/DRILL-6145
> Project: Apache Drill
>  Issue Type: Bug
>  Components: Storage - Hive, Storage - MapRDB
>Affects Versions: 1.12.0
>Reporter: Vitalii Diravka
>Assignee: Vitalii Diravka
>Priority: Major
>  Labels: doc-impacting
> Fix For: 1.14.0
>
>
> Similar to "hive-hbase-storage-handler" to support querying MapR-DB Hive's 
> external tables it is necessary to add "hive-maprdb-json-handler".
> Use case:
>  # Create a table MapR-DB JSON table:
> {code}
> _> mapr dbshell_
> _maprdb root:> create /tmp/table/json_  (make sure /tmp/table exists)
> {code}
> -- insert data
> {code}
> insert /tmp/table/json --value '\{"_id":"movie002" , "title":"Developers 
> on the Edge", "studio":"Command Line Studios"}'
> insert /tmp/table/json --id movie003 --value '\{"title":"The Golden 
> Master", "studio":"All-Nighter"}'
> {code} 
>  #  Create a Hive external table:
> {code}
> CREATE EXTERNAL TABLE mapr_db_json_hive_tbl ( 
> movie_id string, title string, studio string) 
> STORED BY 'org.apache.hadoop.hive.maprdb.json.MapRDBJsonStorageHandler' 
> TBLPROPERTIES("maprdb.table.name" = "/tmp/table/json","maprdb.column.id" = 
> "movie_id");
> {code}
>  
>  #  Use hive schema to query this table:
> {code}
> select * from hive.mapr_db_json_hive_tbl;
> {code}



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

[jira] [Updated] (DRILL-5120) Upgrade JDBC Driver for new Java 8 methods

[Pritesh Maker (JIRA)]

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

Pritesh Maker updated DRILL-5120:
-
Issue Type: Improvement  (was: Bug)

> Upgrade JDBC Driver for new Java 8 methods
> --
>
> Key: DRILL-5120
> URL: https://issues.apache.org/jira/browse/DRILL-5120
> Project: Apache Drill
>  Issue Type: Improvement
>  Components: Client - JDBC
>Affects Versions: 1.8.0
>Reporter: Paul Rogers
>Priority: Minor
>
> Java 8 has been released for some time. Included in Java 8 is a new version 
> of the JDBC interface: JDBC 4.2. Consult the JDBC spec for details.
> The JDBC unit tests were modified to pass with the default JDBC 4.2 
> implementations. The "known not implemented" code (marked with TODO) should 
> be replaced to test the real implementations.



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

[jira] [Assigned] (DRILL-6163) Switch Travis To Java 8

[Pritesh Maker (JIRA)]

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

Pritesh Maker reassigned DRILL-6163:


Assignee: Volodymyr Tkach  (was: Timothy Farkas)

> Switch Travis To Java 8
> ---
>
> Key: DRILL-6163
> URL: https://issues.apache.org/jira/browse/DRILL-6163
> Project: Apache Drill
>  Issue Type: Improvement
>Reporter: Timothy Farkas
>Assignee: Volodymyr Tkach
>Priority: Major
>
> Drill is preparing to move to Java 8 for the next release. So we should make 
> Travis test with Java 8 as well.



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

[jira] [Assigned] (DRILL-6218) Update release profile to not generate MD5 checksum

[Arina Ielchiieva (JIRA)]

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

Arina Ielchiieva reassigned DRILL-6218:
---

Assignee: Parth Chandra  (was: Arina Ielchiieva)

> Update release profile to not generate MD5 checksum
> ---
>
> Key: DRILL-6218
> URL: https://issues.apache.org/jira/browse/DRILL-6218
> Project: Apache Drill
>  Issue Type: Task
>Affects Versions: 1.12.0
>Reporter: Parth Chandra
>Assignee: Parth Chandra
>Priority: Major
>  Labels: ready-to-commit
> Fix For: 1.13.0
>
>
> Latest release guidelines require that we not generate a MD5 checksum.



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

[jira] [Updated] (DRILL-6218) Update release profile to not generate MD5 checksum

[Arina Ielchiieva (JIRA)]

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

Arina Ielchiieva updated DRILL-6218:

Reviewer: Arina Ielchiieva

> Update release profile to not generate MD5 checksum
> ---
>
> Key: DRILL-6218
> URL: https://issues.apache.org/jira/browse/DRILL-6218
> Project: Apache Drill
>  Issue Type: Task
>Affects Versions: 1.12.0
>Reporter: Parth Chandra
>Assignee: Parth Chandra
>Priority: Major
>  Labels: ready-to-commit
> Fix For: 1.13.0
>
>
> Latest release guidelines require that we not generate a MD5 checksum.



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

[jira] [Updated] (DRILL-6218) Update release profile to not generate MD5 checksum

[Arina Ielchiieva (JIRA)]

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

Arina Ielchiieva updated DRILL-6218:

Fix Version/s: 1.13.0

> Update release profile to not generate MD5 checksum
> ---
>
> Key: DRILL-6218
> URL: https://issues.apache.org/jira/browse/DRILL-6218
> Project: Apache Drill
>  Issue Type: Bug
>Affects Versions: 1.12.0
>Reporter: Parth Chandra
>Assignee: Arina Ielchiieva
>Priority: Major
>  Labels: ready-to-commit
> Fix For: 1.13.0
>
>
> Latest release guidelines require that we not generate a MD5 checksum.



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

[jira] [Assigned] (DRILL-6218) Update release profile to not generate MD5 checksum

[Arina Ielchiieva (JIRA)]

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

Arina Ielchiieva reassigned DRILL-6218:
---

Assignee: Arina Ielchiieva  (was: Parth Chandra)

> Update release profile to not generate MD5 checksum
> ---
>
> Key: DRILL-6218
> URL: https://issues.apache.org/jira/browse/DRILL-6218
> Project: Apache Drill
>  Issue Type: Bug
>Affects Versions: 1.12.0
>Reporter: Parth Chandra
>Assignee: Arina Ielchiieva
>Priority: Major
>  Labels: ready-to-commit
> Fix For: 1.13.0
>
>
> Latest release guidelines require that we not generate a MD5 checksum.



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

[jira] [Updated] (DRILL-6218) Update release profile to not generate MD5 checksum

[Arina Ielchiieva (JIRA)]

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

Arina Ielchiieva updated DRILL-6218:

Labels: ready-to-commit  (was: )

> Update release profile to not generate MD5 checksum
> ---
>
> Key: DRILL-6218
> URL: https://issues.apache.org/jira/browse/DRILL-6218
> Project: Apache Drill
>  Issue Type: Task
>Affects Versions: 1.12.0
>Reporter: Parth Chandra
>Assignee: Arina Ielchiieva
>Priority: Major
>  Labels: ready-to-commit
> Fix For: 1.13.0
>
>
> Latest release guidelines require that we not generate a MD5 checksum.



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

[jira] [Updated] (DRILL-6218) Update release profile to not generate MD5 checksum

[Arina Ielchiieva (JIRA)]

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

Arina Ielchiieva updated DRILL-6218:

Issue Type: Task  (was: Bug)

> Update release profile to not generate MD5 checksum
> ---
>
> Key: DRILL-6218
> URL: https://issues.apache.org/jira/browse/DRILL-6218
> Project: Apache Drill
>  Issue Type: Task
>Affects Versions: 1.12.0
>Reporter: Parth Chandra
>Assignee: Arina Ielchiieva
>Priority: Major
>  Labels: ready-to-commit
> Fix For: 1.13.0
>
>
> Latest release guidelines require that we not generate a MD5 checksum.



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

[jira] [Updated] (DRILL-6218) Update release profile to not generate MD5 checksum

[Arina Ielchiieva (JIRA)]

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

Arina Ielchiieva updated DRILL-6218:

Affects Version/s: 1.12.0

> Update release profile to not generate MD5 checksum
> ---
>
> Key: DRILL-6218
> URL: https://issues.apache.org/jira/browse/DRILL-6218
> Project: Apache Drill
>  Issue Type: Bug
>Affects Versions: 1.12.0
>Reporter: Parth Chandra
>Assignee: Arina Ielchiieva
>Priority: Major
>  Labels: ready-to-commit
> Fix For: 1.13.0
>
>
> Latest release guidelines require that we not generate a MD5 checksum.



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

[jira] [Commented] (DRILL-6218) Update release profile to not generate MD5 checksum

[ASF GitHub Bot (JIRA)]

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

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

Github user arina-ielchiieva commented on the issue:

https://github.com/apache/drill/pull/1156
  
This is due to new checksum file Release Distribution Policy, +1


> Update release profile to not generate MD5 checksum
> ---
>
> Key: DRILL-6218
> URL: https://issues.apache.org/jira/browse/DRILL-6218
> Project: Apache Drill
>  Issue Type: Bug
>Affects Versions: 1.12.0
>Reporter: Parth Chandra
>Assignee: Parth Chandra
>Priority: Major
>  Labels: ready-to-commit
> Fix For: 1.13.0
>
>
> Latest release guidelines require that we not generate a MD5 checksum.



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

[jira] [Commented] (DRILL-6218) Update release profile to not generate MD5 checksum

[ASF GitHub Bot (JIRA)]

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

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

GitHub user parthchandra opened a pull request:

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

DRILL-6218: Update release profile to not generate MD5 checksum

@arina-ielchiieva, @amansinha100, please review

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

$ git pull https://github.com/parthchandra/drill DRILL-6218

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

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


commit a9c4cfde7ae41a42d396178b29c451d21a2daca7
Author: Parth Chandra 
Date:   2018-03-07T09:53:42Z

DRILL-6218: Update release profile to not generate MD5 checksum




> Update release profile to not generate MD5 checksum
> ---
>
> Key: DRILL-6218
> URL: https://issues.apache.org/jira/browse/DRILL-6218
> Project: Apache Drill
>  Issue Type: Bug
>Reporter: Parth Chandra
>Assignee: Parth Chandra
>Priority: Major
>
> Latest release guidelines require that we not generate a MD5 checksum.



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

[jira] [Commented] (DRILL-6213) During restart drillbit should be killed forcefully if exceeds allowed timeout

[ASF GitHub Bot (JIRA)]

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

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

GitHub user arina-ielchiieva opened a pull request:

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

DRILL-6213: During restart drillbit should be killed forcefully if ex…

…ceeds allowed timeout

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

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

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

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


commit 23790b46c08963a0a41468883feaea6e1f3a22b3
Author: Arina Ielchiieva 
Date:   2018-03-07T10:35:30Z

DRILL-6213: During restart drillbit should be killed forcefully if exceeds 
allowed timeout




> During restart drillbit should be killed forcefully if exceeds allowed timeout
> --
>
> Key: DRILL-6213
> URL: https://issues.apache.org/jira/browse/DRILL-6213
> Project: Apache Drill
>  Issue Type: Task
>Affects Versions: 1.12.0
> Environment:  
>  
>  
>Reporter: Arina Ielchiieva
>Assignee: Arina Ielchiieva
>Priority: Major
>
> drillbit.sh can start / stop drillbit. Stop command will stop drillbit 
> softly. If drillbit is not stopped during pre-defined time, it it will be 
> killed forcefully (-9).
> There is also restart command which basically behaves like stop + start. But 
> in this case stop command is called without kill forcefully flag. This leads 
> to the cases when executing restart it hangs since driilbit is not be able to 
> be killed softly and retries to do it forever.



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

[jira] [Assigned] (DRILL-6213) During restart drillbit should be killed forcefully if exceeds allowed timeout

[Arina Ielchiieva (JIRA)]

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

Arina Ielchiieva reassigned DRILL-6213:
---

Assignee: Arina Ielchiieva

> During restart drillbit should be killed forcefully if exceeds allowed timeout
> --
>
> Key: DRILL-6213
> URL: https://issues.apache.org/jira/browse/DRILL-6213
> Project: Apache Drill
>  Issue Type: Task
>Affects Versions: 1.12.0
> Environment:  
>  
>  
>Reporter: Arina Ielchiieva
>Assignee: Arina Ielchiieva
>Priority: Major
>
> drillbit.sh can start / stop drillbit. Stop command will stop drillbit 
> softly. If drillbit is not stopped during pre-defined time, it it will be 
> killed forcefully (-9).
> There is also restart command which basically behaves like stop + start. But 
> in this case stop command is called without kill forcefully flag. This leads 
> to the cases when executing restart it hangs since driilbit is not be able to 
> be killed softly and retries to do it forever.



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

[jira] [Updated] (DRILL-6217) NaN/Inf: NestedLoopJoin processes NaN values incorrectly

[Arina Ielchiieva (JIRA)]

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

Arina Ielchiieva updated DRILL-6217:

Affects Version/s: 1.12.0
 Reviewer: Arina Ielchiieva
Fix Version/s: 1.13.0

> NaN/Inf: NestedLoopJoin processes NaN values incorrectly
> 
>
> Key: DRILL-6217
> URL: https://issues.apache.org/jira/browse/DRILL-6217
> Project: Apache Drill
>  Issue Type: Bug
>Affects Versions: 1.12.0
>Reporter: Volodymyr Tkach
>Assignee: Volodymyr Tkach
>Priority: Major
> Fix For: 1.13.0
>
> Attachments: ObjsX.json
>
>
> *AFFECTED_FUNCTIONALITY:* INNER JOIN (nestedloopjoin)
> *ISSUE_DESCRIPTION:* according to *nestedloopjoin* query result NaN != NaN, 
> however hashjoin / mergejoin behaves another way - NaN = NaN. As far as I 
> understand, nestedloopjoin should behave like hashjoin / mergejoin. *STEPS*:
> - Upload the attached file to Hadoop fs (ObjsX.json);
> - Setup the following system settings:
>   *set planner.enable_nljoin_for_scalar_only = false*
>   *set planner.enable_hashjoin = false*
>   *set planner.enable_mergejoin = false*
>   *set planner.enable_nestedloopjoin = true*
> - Run the following sql query {code} select distinct t.name from 
> dfs.tmp.`ObjsX.json` t inner join dfs.tmp.`ObjsX.json` tt on t.attr4 = 
> tt.attr4 {code}
>   *EXPECTED_RESULT:* It was expected to get the following result:
>   {code}
>object1
>object2
>object3
>object4
>   {code}
>   
>   *ACTUAL_RESULT:* The actual result is:
>   {code}
>object2
>object3
>object4
>   {code}
> Please investigate and fix



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

[jira] [Commented] (DRILL-6118) Handle item star columns during project / filter push down and directory pruning

[ASF GitHub Bot (JIRA)]

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

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

Github user vvysotskyi commented on the issue:

https://github.com/apache/drill/pull/1104
  
@paul-rogers, as you know, there were some differences between the commits 
in the older Calcite version (1.4.0-r23) which was used by Drill and commits 
merged into Apache master. One of such commits was `[CALCITE-1150] Add dynamic 
record type and dynamic star for schema-on-read table`. In our older Calcite 
fork `DYNAMIC_STAR` was `*`, but after rebase onto Calcite 1.15, it became `**`.

As I understand, `DYNAMIC_STAR` itself means "default column" which will be 
added to table row type for the case when we have `select *` query and the 
schema of the underlying table is not known. 

As for the name of constant, I think current `DYNAMIC_STAR` more suitable, 
since Calcite also uses a similar name for the same string: 
`DynamicRecordType.DYNAMIC_STAR_PREFIX`. So current name at least helps to 
avoid divergence in naming for Drill and Calcite.


> Handle item star columns during project  /  filter push down and directory 
> pruning
> --
>
> Key: DRILL-6118
> URL: https://issues.apache.org/jira/browse/DRILL-6118
> Project: Apache Drill
>  Issue Type: Improvement
>Affects Versions: 1.12.0
>Reporter: Arina Ielchiieva
>Assignee: Arina Ielchiieva
>Priority: Major
>  Labels: doc-impacting, ready-to-commit
> Fix For: 1.13.0
>
>
> Project push down, filter push down and partition pruning does not work with 
> dynamically expanded column with is represented as star in ITEM operator: 
> _ITEM($0, 'column_name')_ where $0 is a star.
>  This often occurs when view, sub-select or cte with star is issued.
>  To solve this issue we can create {{DrillFilterItemStarReWriterRule}} which 
> will rewrite such ITEM operator before filter push down and directory 
> pruning. For project into scan push down logic will be handled separately in 
> already existing rule {{DrillPushProjectIntoScanRule}}. Basically, we can 
> consider the following queries the same: 
>  {{select col1 from t}}
>  {{select col1 from (select * from t)}}
> *Use cases*
> Since item star columns where not considered during project / filter push 
> down and directory pruning, push down and pruning did not happen. This was 
> causing Drill to read all columns from file (when only several are needed) or 
> ready all files instead. Views with star query is the most common example. 
> Such behavior significantly degrades performance for item star queries 
> comparing to queries without item star.
> *EXAMPLES*
> *Data set* 
> will create table with three files each in dedicated sub-folder:
> {noformat}
> use dfs.tmp;
> create table `order_ctas/t1` as select cast(o_orderdate as date) as 
> o_orderdate from cp.`tpch/orders.parquet` where o_orderdate between date 
> '1992-01-01' and date '1992-01-03';
> create table `order_ctas/t2` as select cast(o_orderdate as date) as 
> o_orderdate from cp.`tpch/orders.parquet` where o_orderdate between date 
> '1992-01-04' and date '1992-01-06';
> create table `order_ctas/t3` as select cast(o_orderdate as date) as 
> o_orderdate from cp.`tpch/orders.parquet` where o_orderdate between date 
> '1992-01-07' and date '1992-01-09';
> {noformat}
> *Filter push down*
> {{select * from order_ctas where o_orderdate = date '1992-01-01'}} will read 
> only one file
> {noformat}
> 00-00Screen
> 00-01  Project(**=[$0])
> 00-02Project(T1¦¦**=[$0])
> 00-03  SelectionVectorRemover
> 00-04Filter(condition=[=($1, 1992-01-01)])
> 00-05  Project(T1¦¦**=[$0], o_orderdate=[$1])
> 00-06Scan(groupscan=[ParquetGroupScan 
> [entries=[ReadEntryWithPath [path=/tmp/order_ctas/t1/0_0_0.parquet]], 
> selectionRoot=/tmp/order_ctas, numFiles=1, numRowGroups=1, 
> usedMetadataFile=false, columns=[`**`]]])
> {noformat}
> {{select * from (select * from order_ctas) where o_orderdate = date 
> '1992-01-01'}} will ready all three files
> {noformat}
> 00-00Screen
> 00-01  Project(**=[$0])
> 00-02SelectionVectorRemover
> 00-03  Filter(condition=[=(ITEM($0, 'o_orderdate'), 1992-01-01)])
> 00-04Scan(groupscan=[ParquetGroupScan [entries=[ReadEntryWithPath 
> [path=/tmp/order_ctas/t1/0_0_0.parquet], ReadEntryWithPath 
> [path=/tmp/order_ctas/t2/0_0_0.parquet], ReadEntryWithPath 
> [path=/tmp/order_ctas/t3/0_0_0.parquet]], selectionRoot=/tmp/order_ctas, 
> numFiles=3, numRowGroups=3, usedMetadataFile=false, columns=[`**`]]])
> {noformat}
> *Directory pruning*
> {{select * from order_ctas where dir0 = 't1'}} will read data only from 

[jira] [Assigned] (DRILL-5239) Drill text reader reports wrong results when column value starts with '#'

[Arina Ielchiieva (JIRA)]

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

Arina Ielchiieva reassigned DRILL-5239:
---

Assignee: (was: Roman Kulyk)

> Drill text reader reports wrong results when column value starts with '#'
> -
>
> Key: DRILL-5239
> URL: https://issues.apache.org/jira/browse/DRILL-5239
> Project: Apache Drill
>  Issue Type: Bug
>  Components: Storage - Text  CSV
>Affects Versions: 1.10.0
>Reporter: Rahul Challapalli
>Priority: Blocker
>  Labels: doc-impacting
>
> git.commit.id.abbrev=2af709f
> Data Set :
> {code}
> D|32
> 8h|234
> ;#|3489
> ^$*(|308
> #|98
> {code}
> Wrong Result : (Last row is missing)
> {code}
> select columns[0] as col1, columns[1] as col2 from 
> dfs.`/drill/testdata/wtf2.tbl`;
> +---+---+
> | col1  | col2  |
> +---+---+
> | D | 32|
> | 8h| 234   |
> | ;#| 3489  |
> | ^$*(  | 308   |
> +---+---+
> 4 rows selected (0.233 seconds)
> {code}
> The issue does not however happen with a parquet file



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

[jira] [Updated] (DRILL-6125) PartitionSenderRootExec can leak memory because close method is not synchronized

[Arina Ielchiieva (JIRA)]

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

Arina Ielchiieva updated DRILL-6125:

Reviewer: Vlad Rozov  (was: Arina Ielchiieva)

> PartitionSenderRootExec can leak memory because close method is not 
> synchronized
> 
>
> Key: DRILL-6125
> URL: https://issues.apache.org/jira/browse/DRILL-6125
> Project: Apache Drill
>  Issue Type: Bug
>Affects Versions: 1.13.0
>Reporter: Timothy Farkas
>Assignee: Timothy Farkas
>Priority: Minor
> Fix For: 1.14.0
>
>
> PartitionSenderRootExec creates a PartitionerDecorator and saves it in the 
> *partitioner* field. The creation of the partitioner happens in the 
> createPartitioner method. This method get's called by the main fragment 
> thread. The partitioner field is accessed by the fragment thread during 
> normal execution but it can also be accessed by the receivingFragmentFinished 
> method which is a callback executed by the event processor thread. Because 
> multiple threads can access the partitioner field synchronization is done on 
> creation and on when receivingFragmentFinished. However, the close method can 
> also be called by the event processor thread, and the close method does not 
> synchronize before accessing the partitioner field. Since synchronization is 
> not done the event processor thread may have an old reference to the 
> partitioner when a query cancellation is done. Since it has an old reference 
> the current partitioner can may not be cleared and a memory leak may occur.



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

[jira] [Commented] (DRILL-4120) dir0 does not work when the directory structure contains Avro files

[ASF GitHub Bot (JIRA)]

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

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

Github user arina-ielchiieva commented on the issue:

https://github.com/apache/drill/pull/1138
  
+1. LGTM.


> dir0 does not work when the directory structure contains Avro files
> ---
>
> Key: DRILL-4120
> URL: https://issues.apache.org/jira/browse/DRILL-4120
> Project: Apache Drill
>  Issue Type: Bug
>  Components: Query Planning  Optimization, Storage - Avro
>Affects Versions: 1.3.0
>Reporter: Stefán Baxter
>Assignee: Volodymyr Vysotskyi
>Priority: Major
>  Labels: ready-to-commit
> Fix For: 1.13.0
>
> Attachments: 
> 0001-DRILL-4120-Support-reading-directories-having-avro-f.patch
>
>
> Any select statment containing dirN fails if the target directory structure 
> contains Avro files.
> Steps to test:
> 1. create a simple directory structure
> 2. copy an avro file into each directory
> 3. execute a query containing dir0
> outcome:
> Error: VALIDATION ERROR: From line 1, column 117 to line 1, column 120: 
> Column 'dir0' not found in any table



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

[jira] [Updated] (DRILL-4120) dir0 does not work when the directory structure contains Avro files

[Arina Ielchiieva (JIRA)]

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

Arina Ielchiieva updated DRILL-4120:

Labels: ready-to-commit  (was: )

> dir0 does not work when the directory structure contains Avro files
> ---
>
> Key: DRILL-4120
> URL: https://issues.apache.org/jira/browse/DRILL-4120
> Project: Apache Drill
>  Issue Type: Bug
>  Components: Query Planning  Optimization, Storage - Avro
>Affects Versions: 1.3.0
>Reporter: Stefán Baxter
>Assignee: Volodymyr Vysotskyi
>Priority: Major
>  Labels: ready-to-commit
> Fix For: 1.13.0
>
> Attachments: 
> 0001-DRILL-4120-Support-reading-directories-having-avro-f.patch
>
>
> Any select statment containing dirN fails if the target directory structure 
> contains Avro files.
> Steps to test:
> 1. create a simple directory structure
> 2. copy an avro file into each directory
> 3. execute a query containing dir0
> outcome:
> Error: VALIDATION ERROR: From line 1, column 117 to line 1, column 120: 
> Column 'dir0' not found in any table



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

[jira] [Updated] (DRILL-6021) Show shutdown button when authentication is not enabled

[Arina Ielchiieva (JIRA)]

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

Arina Ielchiieva updated DRILL-6021:

Labels: ready-to-commit  (was: )

> Show shutdown button when authentication is not enabled
> ---
>
> Key: DRILL-6021
> URL: https://issues.apache.org/jira/browse/DRILL-6021
> Project: Apache Drill
>  Issue Type: Bug
>Affects Versions: 1.12.0
>Reporter: Arina Ielchiieva
>Assignee: Venkata Jyothsna Donapati
>Priority: Major
>  Labels: ready-to-commit
> Fix For: 1.13.0
>
>
> After DRILL-6017 {{shouldShowAdminInfo}} is used to decide if shutdown button 
> should be displayed on index page. But this option is set to true when 
> authentication is enabled and user is an admin. When authentication is not 
> enabled, user by default is admin. So with this fix without authentication, 
> shutdown button is absent but should be present.



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

[jira] [Commented] (DRILL-6021) Show shutdown button when authentication is not enabled

[ASF GitHub Bot (JIRA)]

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

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

Github user arina-ielchiieva commented on the issue:

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


> Show shutdown button when authentication is not enabled
> ---
>
> Key: DRILL-6021
> URL: https://issues.apache.org/jira/browse/DRILL-6021
> Project: Apache Drill
>  Issue Type: Bug
>Affects Versions: 1.12.0
>Reporter: Arina Ielchiieva
>Assignee: Venkata Jyothsna Donapati
>Priority: Major
> Fix For: 1.13.0
>
>
> After DRILL-6017 {{shouldShowAdminInfo}} is used to decide if shutdown button 
> should be displayed on index page. But this option is set to true when 
> authentication is enabled and user is an admin. When authentication is not 
> enabled, user by default is admin. So with this fix without authentication, 
> shutdown button is absent but should be present.



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

[jira] [Created] (DRILL-6218) Update release profile to not generate MD5 checksum

[Parth Chandra (JIRA)]

Parth Chandra created DRILL-6218:


 Summary: Update release profile to not generate MD5 checksum
 Key: DRILL-6218
 URL: https://issues.apache.org/jira/browse/DRILL-6218
 Project: Apache Drill
  Issue Type: Bug
Reporter: Parth Chandra
Assignee: Parth Chandra


Latest release guidelines require that we not generate a MD5 checksum.



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

[jira] [Created] (DRILL-6217) NaN/Inf: NestedLoopJoin processes NaN values incorrectly

[Volodymyr Tkach (JIRA)]

Volodymyr Tkach created DRILL-6217:
--

 Summary: NaN/Inf: NestedLoopJoin processes NaN values incorrectly
 Key: DRILL-6217
 URL: https://issues.apache.org/jira/browse/DRILL-6217
 Project: Apache Drill
  Issue Type: Bug
Reporter: Volodymyr Tkach
Assignee: Volodymyr Tkach
 Attachments: ObjsX.json

*AFFECTED_FUNCTIONALITY:* INNER JOIN (nestedloopjoin)

*ISSUE_DESCRIPTION:* according to *nestedloopjoin* query result NaN != NaN, 
however hashjoin / mergejoin behaves another way - NaN = NaN. As far as I 
understand, nestedloopjoin should behave like hashjoin / mergejoin. *STEPS*:
- Upload the attached file to Hadoop fs (ObjsX.json);
- Setup the following system settings:
*set planner.enable_nljoin_for_scalar_only = false*
*set planner.enable_hashjoin = false*
*set planner.enable_mergejoin = false*
*set planner.enable_nestedloopjoin = true*
- Run the following sql query {code} select distinct t.name from 
dfs.tmp.`ObjsX.json` t inner join dfs.tmp.`ObjsX.json` tt on t.attr4 = tt.attr4 
{code}
*EXPECTED_RESULT:* It was expected to get the following result:
{code}
 object1
 object2
 object3
 object4
{code}

*ACTUAL_RESULT:* The actual result is:
{code}
 object2
 object3
 object4
{code}

Please investigate and fix



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