[jira] [Updated] (DRILL-6952) Merge row set based "compliant" text reader
[ https://issues.apache.org/jira/browse/DRILL-6952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Rogers updated DRILL-6952: --- Reviewer: Arina Ielchiieva > Merge row set based "compliant" text reader > --- > > Key: DRILL-6952 > URL: https://issues.apache.org/jira/browse/DRILL-6952 > Project: Apache Drill > Issue Type: Improvement >Affects Versions: 1.15.0 >Reporter: Paul Rogers >Assignee: Paul Rogers >Priority: Major > Fix For: 1.16.0 > > > The result set loader project created a revised version of the compliant text > reader that uses the result set loader framework (which includes the > schema-based projection framework.) > This task merges that work into master: > * Review the history of the complaint text reader for changes made in the > last year since the code was written. > * Apply those changes to the row set-based code, as necessary. > * Issue a PR for the new version of the compliant text reader > * Work through any test issues that crop up in the pre-commit tests. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (DRILL-7083) Wrong data type for explicit partition column beyond file depth
Paul Rogers created DRILL-7083:
--
Summary: Wrong data type for explicit partition column beyond file
depth
Key: DRILL-7083
URL: https://issues.apache.org/jira/browse/DRILL-7083
Project: Apache Drill
Issue Type: Bug
Affects Versions: 1.15.0
Reporter: Paul Rogers
Consider the simple case in DRILL-7082. That ticket talks about implicit
partition columns created by the wildcard. Consider a very similar case:
{code:sql}
SELECT a, b, c, dir0, dir1 FROM `myTable`
{code}
Where {{myTable}} is a directory of CSV files, each with schema {{(a, b, c)}}:
{noformat}
myTable
|- file1.csv
|- nested
|- file2.csv
{noformat}
If the query is run in "stock" Drill, the planner will place both files within
a single scan operator as described in DRILL-7082. The result schema will be:
{noformat}
(a VARCHAR, b VARCHAR, c VARCHAR, dir0 VARCHAR, dir1 INT)
{noformat}
Notice that last column: why is "dir1" a (nullable) INT? The partition
mechanism only recognizes partitions that actually exist, leaving the Project
operator to fill in (with a Nullable INT) any partitions that don't exist (any
directory levels not actually seen by the scan operator.)
Now, using the same trick as in DRILL-7082, try the query
{code:sql}
SELECT a, b, c, dir0 FROM `myTable`
{code}
Again, the trick causes Drill to read each file in a separate scan operator
(simulating what happens when queries run at scale.)
The scan operator for {{file1.csv}} will see no partitions, so it will omit
"dir0" and the Project operator will helpfully fill in a Nullable INT. The scan
operator for {{file2.csv}} sees one level of partition, so sets {{dir0}} to
{{nested}} as a Nullable VARCHAR.
What does the client see? Two records: one with "dir0" as a Nullable INT, the
other as a Nullable VARCHAR. Client such as JDBC and ODBC see a hard schema
change between the two records.
The two cases described above are really two versions of the same issue.
Clients expect that, if they use the "dir0", "dir1", ... columns, that the type
is always Nullable Varchar so that the schema stays consistent across batches.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (DRILL-7082) Inconsistent results with implicit partition columns, multi scans
[
https://issues.apache.org/jira/browse/DRILL-7082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Rogers reassigned DRILL-7082:
--
Assignee: (was: Paul Rogers)
> Inconsistent results with implicit partition columns, multi scans
> -
>
> Key: DRILL-7082
> URL: https://issues.apache.org/jira/browse/DRILL-7082
> Project: Apache Drill
> Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Paul Rogers
>Priority: Minor
>
> The runtime behavior of implicit partition columns is wildly inconsistent to
> the point of being unusable. Consider the following query:
> {code:sql}
> SELECT * FROM `myTable`
> {code}
> Where {{myTable}} is a directory of CSV files, each with schema {{(a, b, c)}}:
> {noformat}
> myTable
> |- file1.csv
> |- nested
>|- file2.csv
> {noformat}
> Our test files are small. Turn out that, even if we write a test that scans a
> few files, such as the above example, Drill will group all the reads into a
> single fragment with a single scan operator. When that happens:
> * The partition columns appear before the data columns: (dir0, a, b, c).
> * The partition columns always appear in every row.
> We get the above result because a single scan operator sees both files and
> knows the right number of partition columns to create for each.
> But, we know that, if two scans each read files at different depths, the
> "shallower" one won't see as many partition directories as the "deeper" one.
> To test this, I modified the text reader to accept a new session option that
> sets the minimum parallelization. I set it to 2 (same as the number of
> files.) One could probably also see this by creating large text files so that
> the Drill parallelizer will choose to create two fragments.
> Then, I ran the above query 10 times. Now, I get these results:
> * Half the time, the first row has only the data columns (a, b, c), the other
> half of the time the first row has a partition column. (Depending on which
> file returned data first.)
> * Some of the time the partition column appears in the first position (dir0,
> a, b, c) and some of the time in the last (a, b, c, dir0). (I have no idea
> why.)
> The result is, from a two-file query, depending on random factors, your first
> row schema could be:
> * (a, b, c)
> * (dir0, a, b, c)
> * (a, b, c, dir0)
> In many cases, the second row comes with a hard schema change to a different
> format.
> The above is demonstrated in the (soon to be provided) {{TestPartitionRace}}
> unit test.
> IMHO, the behavior is basically unusable as any JDBC/ODBC client will see an
> inconsistent, changing schema. Instead, what a user would expect is:
> * The partition columns are in the same location in every row (preferably at
> the end, so data columns remain in fixed positions regardless of the number
> of partition columns.)
> * The same number of columns in every row. This means that all scan operators
> must use a single uniform partition depth count, preferably set at plan type
> in the group scan node that has visibility to all the files to scan.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (DRILL-7056) Drill fails with NPE when starting in distributed mode and 31010 port is used
[
https://issues.apache.org/jira/browse/DRILL-7056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Volodymyr Vysotskyi updated DRILL-7056:
---
Labels: ready-to-commit (was: )
> Drill fails with NPE when starting in distributed mode and 31010 port is used
> -
>
> Key: DRILL-7056
> URL: https://issues.apache.org/jira/browse/DRILL-7056
> Project: Apache Drill
> Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Volodymyr Vysotskyi
>Assignee: Kunal Khatua
>Priority: Major
> Labels: ready-to-commit
> Fix For: 1.16.0
>
>
> Steps to reproduce:
> 1. Run process which uses 31010 port, for example, execute the following code:
> {code:java}
> try (Socket localhost = new Socket("localhost", 31010)) {
> Thread.sleep(500_000);
> }
> {code}
> 2. Start Drill in distributed mode.
> As the result, Drill is not started and the following stack trace with NPE in
> {{drillbit.log}}:
> {noformat}
> [Error Id: 2600a33d-c06d-4361-a39b-8f4b3d05b639 ]
> at
> org.apache.drill.common.exceptions.UserException$Builder.build(UserException.java:633)
> ~[drill-common-1.16.0-SNAPSHOT.jar:1.16.0-SNAPSHOT]
> at org.apache.drill.exec.rpc.BasicServer.bind(BasicServer.java:211)
> ~[drill-rpc-1.16.0-SNAPSHOT.jar:1.16.0-SNAPSHOT]
> at
> org.apache.drill.exec.service.ServiceEngine.start(ServiceEngine.java:100)
> ~[drill-java-exec-1.16.0-SNAPSHOT.jar:1.16.0-SNAPSHOT]
> at org.apache.drill.exec.server.Drillbit.run(Drillbit.java:207)
> [drill-java-exec-1.16.0-SNAPSHOT.jar:1.16.0-SNAPSHOT]
> at org.apache.drill.exec.server.Drillbit.start(Drillbit.java:527)
> [drill-java-exec-1.16.0-SNAPSHOT.jar:1.16.0-SNAPSHOT]
> at org.apache.drill.exec.server.Drillbit.start(Drillbit.java:497)
> [drill-java-exec-1.16.0-SNAPSHOT.jar:1.16.0-SNAPSHOT]
> at org.apache.drill.exec.server.Drillbit.main(Drillbit.java:493)
> [drill-java-exec-1.16.0-SNAPSHOT.jar:1.16.0-SNAPSHOT]
> java.net.BindException: Address already in use
> at sun.nio.ch.Net.bind0(Native Method) ~[na:1.8.0_191]
> at sun.nio.ch.Net.bind(Net.java:433) ~[na:1.8.0_191]
> at sun.nio.ch.Net.bind(Net.java:425) ~[na:1.8.0_191]
> at
> sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
> ~[na:1.8.0_191]
> at
> io.netty.channel.socket.nio.NioServerSocketChannel.doBind(NioServerSocketChannel.java:128)
> ~[netty-transport-4.0.48.Final.jar:4.0.48.Final]
> at
> io.netty.channel.AbstractChannel$AbstractUnsafe.bind(AbstractChannel.java:500)
> ~[netty-transport-4.0.48.Final.jar:4.0.48.Final]
> at
> io.netty.channel.DefaultChannelPipeline$HeadContext.bind(DefaultChannelPipeline.java:1218)
> ~[netty-transport-4.0.48.Final.jar:4.0.48.Final]
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeBind(AbstractChannelHandlerContext.java:495)
> ~[netty-transport-4.0.48.Final.jar:4.0.48.Final]
> at
> io.netty.channel.AbstractChannelHandlerContext.bind(AbstractChannelHandlerContext.java:480)
> ~[netty-transport-4.0.48.Final.jar:4.0.48.Final]
> at
> io.netty.channel.DefaultChannelPipeline.bind(DefaultChannelPipeline.java:965)
> ~[netty-transport-4.0.48.Final.jar:4.0.48.Final]
> at io.netty.channel.AbstractChannel.bind(AbstractChannel.java:209)
> ~[netty-transport-4.0.48.Final.jar:4.0.48.Final]
> at
> io.netty.bootstrap.AbstractBootstrap$2.run(AbstractBootstrap.java:355)
> ~[netty-transport-4.0.48.Final.jar:4.0.48.Final]
> at
> io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:399)
> ~[netty-common-4.0.48.Final.jar:4.0.48.Final]
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:463)
> ~[netty-transport-4.0.48.Final.jar:4.0.48.Final]
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:131)
> ~[netty-common-4.0.48.Final.jar:4.0.48.Final]
> at java.lang.Thread.run(Thread.java:748) ~[na:1.8.0_191]
> 2019-02-25 17:58:03,888 [main] WARN o.apache.drill.exec.server.Drillbit -
> Failure on close()
> java.lang.NullPointerException: null
> at
> org.apache.drill.exec.server.rest.WebServer.generateOptionsDescriptionJSFile(WebServer.java:480)
> ~[drill-java-exec-1.16.0-SNAPSHOT.jar:1.16.0-SNAPSHOT]
> at
> org.apache.drill.exec.server.rest.WebServer.getTmpJavaScriptDir(WebServer.java:138)
> ~[drill-java-exec-1.16.0-SNAPSHOT.jar:1.16.0-SNAPSHOT]
> at
> org.apache.drill.exec.server.rest.WebServer.close(WebServer.java:471)
> ~[drill-java-exec-1.16.0-SNAPSHOT.jar:1.16.0-SNAPSHOT]
> at
> org.apache.drill.common.AutoCloseables.close(AutoCloseables.java:87)
>
[jira] [Closed] (DRILL-5509) Upgrade Drill protobuf support from 2.5.0 to latest 3.3
[ https://issues.apache.org/jira/browse/DRILL-5509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kunal Khatua closed DRILL-5509. --- Resolution: Duplicate Assignee: Anton Gozhiy Fix Version/s: 1.16.0 Protobuf upgraded to 3.6 > Upgrade Drill protobuf support from 2.5.0 to latest 3.3 > --- > > Key: DRILL-5509 > URL: https://issues.apache.org/jira/browse/DRILL-5509 > Project: Apache Drill > Issue Type: Improvement >Affects Versions: 1.10.0 >Reporter: Paul Rogers >Assignee: Anton Gozhiy >Priority: Minor > Fix For: 1.16.0 > > > Drill uses Google Protobufs for RPC. Drill's Maven compile requires version > 2.5.0 from Feb. 2013. The latest version is 3.3. Over time, it may become > increasingly hard to find and build a four-year-old version. > Upgrade Drill to use the latest Protobuf version. This will require updating > the Maven protobuf plugin, and may require other upgrades as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (DRILL-7081) Upgrade GlassFish Jersey and Javax Servlet dependecies
[ https://issues.apache.org/jira/browse/DRILL-7081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vitalii Diravka updated DRILL-7081: --- Description: DRILL-7051 updates Eclipse Jetty dependencies. There are more dependencies related to Drill WebUI, which are old and should be updated: 1. Set of GlassFish Jersey dependecies 2. Set of Javax Servlet dependecies It requires almost 2M increasing of drill-jdbc-all jar. It is necessary to investigate whether it is possible to exclude some dependencies to reduce the size of the driver. was: DRILL-7051 updates Eclipse Jetty dependencies. There are more dependencies related to Drill WebUI, which are old and should be updated: 1. Set of GlassFish Jersey dependecies 2. Set of Javax Servlet dependecies It requires almost 2M increase of drill-jdbc-all jar. It is necessary to investigate whether it is possible to exclude some dependencies to reduce the size of the driver. > Upgrade GlassFish Jersey and Javax Servlet dependecies > -- > > Key: DRILL-7081 > URL: https://issues.apache.org/jira/browse/DRILL-7081 > Project: Apache Drill > Issue Type: Improvement > Components: Web Server >Affects Versions: 1.15.0 >Reporter: Vitalii Diravka >Assignee: Vitalii Diravka >Priority: Minor > Fix For: 1.16.0 > > > DRILL-7051 updates Eclipse Jetty dependencies. > There are more dependencies related to Drill WebUI, which are old and should > be updated: > 1. Set of GlassFish Jersey dependecies > 2. Set of Javax Servlet dependecies > It requires almost 2M increasing of drill-jdbc-all jar. > It is necessary to investigate whether it is possible to exclude some > dependencies to reduce the size of the driver. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (DRILL-7080) Wrong result schema for wildcard and partition columns
[
https://issues.apache.org/jira/browse/DRILL-7080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Rogers updated DRILL-7080:
---
Summary: Wrong result schema for wildcard and partition columns (was:
Inconsistent behavior with wildcard and partition columns)
> Wrong result schema for wildcard and partition columns
> --
>
> Key: DRILL-7080
> URL: https://issues.apache.org/jira/browse/DRILL-7080
> Project: Apache Drill
> Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Paul Rogers
>Priority: Minor
>
> Drill supports queries of the form:
> {code:sql}
> SELECT *, dir0 FROM `myTable`
> {code}
> Where `myTable` is, say, a set of CSV files with columns "a", "b" and "c". As
> shown in the (soon to be submitted) {{TestCsvWithHeaders}} test, behavior of
> partition columns is wildly inconsistent and nearly unusable. This ticket
> focus on one specific issue: the query above results in a schema like (dir0,
> a, b, c, dir00). That is:
> * The wildcard generates "dir0", "dir1" columns.
> * The Project operator inserts a second column, "dir00" as type Nullable Int.
> This behavior is surprising as the following query produces the expected
> result:
> {code:sql}
> SELECT *, filename from `myTable`
> {code}
> That is, the above produces a schema of the form (a, b, c, filename) with
> "filename" of the expected type: VARCHAR.
> This appears to be a bug somewhere in the project operator and/or the
> planner, but I've not tracked down the root cause.
> The workaround is to either:
> 1. Not include the "dir0" column explicitly with the wildcard, or
> 2. Don't use the wildcard: list columns explicitly, including the partition
> columns.
> Given how late in the game that this bug is filed, I would guess that few
> people actually use this feature.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (DRILL-7082) Inconsistent results with implicit partition columns, multi scans
Paul Rogers created DRILL-7082:
--
Summary: Inconsistent results with implicit partition columns,
multi scans
Key: DRILL-7082
URL: https://issues.apache.org/jira/browse/DRILL-7082
Project: Apache Drill
Issue Type: Bug
Affects Versions: 1.15.0
Reporter: Paul Rogers
Assignee: Paul Rogers
The runtime behavior of implicit partition columns is wildly inconsistent to
the point of being unusable. Consider the following query:
{code:sql}
SELECT * FROM `myTable`
{code}
Where {{myTable}} is a directory of CSV files, each with schema {{(a, b, c)}}:
{noformat}
myTable
|- file1.csv
|- nested
|- file2.csv
{noformat}
Our test files are small. Turn out that, even if we write a test that scans a
few files, such as the above example, Drill will group all the reads into a
single fragment with a single scan operator. When that happens:
* The partition columns appear before the data columns: (dir0, a, b, c).
* The partition columns always appear in every row.
We get the above result because a single scan operator sees both files and
knows the right number of partition columns to create for each.
But, we know that, if two scans each read files at different depths, the
"shallower" one won't see as many partition directories as the "deeper" one. To
test this, I modified the text reader to accept a new session option that sets
the minimum parallelization. I set it to 2 (same as the number of files.) One
could probably also see this by creating large text files so that the Drill
parallelizer will choose to create two fragments.
Then, I ran the above query 10 times. Now, I get these results:
* Half the time, the first row has only the data columns (a, b, c), the other
half of the time the first row has a partition column. (Depending on which file
returned data first.)
* Some of the time the partition column appears in the first position (dir0, a,
b, c) and some of the time in the last (a, b, c, dir0). (I have no idea why.)
The result is, from a two-file query, depending on random factors, your first
row schema could be:
* (a, b, c)
* (dir0, a, b, c)
* (a, b, c, dir0)
In many cases, the second row comes with a hard schema change to a different
format.
The above is demonstrated in the (soon to be provided) {{TestPartitionRace}}
unit test.
IMHO, the behavior is basically unusable as any JDBC/ODBC client will see an
inconsistent, changing schema. Instead, what a user would expect is:
* The partition columns are in the same location in every row (preferably at
the end, so data columns remain in fixed positions regardless of the number of
partition columns.)
* The same number of columns in every row. This means that all scan operators
must use a single uniform partition depth count, preferably set at plan type in
the group scan node that has visibility to all the files to scan.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (DRILL-7081) Upgrade GlassFish Jersey and Javax Servlet dependecies
Vitalii Diravka created DRILL-7081: -- Summary: Upgrade GlassFish Jersey and Javax Servlet dependecies Key: DRILL-7081 URL: https://issues.apache.org/jira/browse/DRILL-7081 Project: Apache Drill Issue Type: Improvement Components: Web Server Affects Versions: 1.15.0 Reporter: Vitalii Diravka Assignee: Vitalii Diravka Fix For: 1.16.0 DRILL-7051 updates Eclipse Jetty dependencies. There are more dependencies related to Drill WebUI, which are old and should be updated: 1. Set of GlassFish Jersey dependecies 2. Set of Javax Servlet dependecies It requires almost 2M increase of drill-jdbc-all jar. It is necessary to investigate whether it is possible to exclude some dependencies to reduce the size of the driver. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (DRILL-7080) Inconsistent behavior with wildcard and partition columns
Paul Rogers created DRILL-7080:
--
Summary: Inconsistent behavior with wildcard and partition columns
Key: DRILL-7080
URL: https://issues.apache.org/jira/browse/DRILL-7080
Project: Apache Drill
Issue Type: Bug
Affects Versions: 1.15.0
Reporter: Paul Rogers
Drill supports queries of the form:
{code:sql}
SELECT *, dir0 FROM `myTable`
{code}
Where `myTable` is, say, a set of CSV files with columns "a", "b" and "c". As
shown in the (soon to be submitted) {{TestCsvWithHeaders}} test, behavior of
partition columns is wildly inconsistent and nearly unusable. This ticket focus
on one specific issue: the query above results in a schema like (dir0, a, b, c,
dir00). That is:
* The wildcard generates "dir0", "dir1" columns.
* The Project operator inserts a second column, "dir00" as type Nullable Int.
This behavior is surprising as the following query produces the expected result:
{code:sql}
SELECT *, filename from `myTable`
{code}
That is, the above produces a schema of the form (a, b, c, filename) with
"filename" of the expected type: VARCHAR.
This appears to be a bug somewhere in the project operator and/or the planner,
but I've not tracked down the root cause.
The workaround is to either:
1. Not include the "dir0" column explicitly with the wildcard, or
2. Don't use the wildcard: list columns explicitly, including the partition
columns.
Given how late in the game that this bug is filed, I would guess that few
people actually use this feature.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (DRILL-7046) Support for loading and parsing new RM config file
[ https://issues.apache.org/jira/browse/DRILL-7046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sorabh Hamirwasia updated DRILL-7046: - Labels: ready-to-commit (was: ) > Support for loading and parsing new RM config file > -- > > Key: DRILL-7046 > URL: https://issues.apache.org/jira/browse/DRILL-7046 > Project: Apache Drill > Issue Type: Sub-task > Components: Execution - Flow >Affects Versions: 1.16.0 >Reporter: Sorabh Hamirwasia >Assignee: Sorabh Hamirwasia >Priority: Major > Labels: ready-to-commit > > This Jira will help to add support for loading new RM specific configuration > file if needed and also parsing it to create all the required in-memory > objects. The details of the new configuration is defined in [Function > Spec|https://docs.google.com/document/d/1cX0lPLL-QzBGUwcekAPvUBgubdcNlWRdy7IG_IFt-Ok/edit?usp=sharing] > RM configuration file will also support override, default and distrib > specific files. It will only be loaded when RM is enabled which will be > controlled by *drill.exec.rm.enabled* parameter in Drill main configuration > file. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (DRILL-7079) Drill can't query views from the S3 storage when plain authentication is enabled
[
https://issues.apache.org/jira/browse/DRILL-7079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arina Ielchiieva updated DRILL-7079:
Fix Version/s: 1.16.0
> Drill can't query views from the S3 storage when plain authentication is
> enabled
>
>
> Key: DRILL-7079
> URL: https://issues.apache.org/jira/browse/DRILL-7079
> Project: Apache Drill
> Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Denys Ordynskiy
>Assignee: Bohdan Kazydub
>Priority: Major
> Fix For: 1.16.0
>
>
> Enable plain authentication in Drill.
> Create the view on the S3 storage:
> create view s3.tmp.`testview` as select * from cp.`employee.json` limit 20;
> Try to select data from the created view:
> select * from s3.tmp.`testview`;
> *Actual result*:
> {noformat}
> 2019-02-27 17:01:09,202 [Client-1] INFO
> o.a.d.j.i.DrillCursor$ResultsListener - [#4] Query failed:
> org.apache.drill.common.exceptions.UserRemoteException: SYSTEM ERROR:
> IllegalArgumentException: A valid userName is expected
> Please, refer to logs for more information.
> [Error Id: 2271c3aa-6d09-4b51-a585-0e0e954b46eb on maprhost:31010]
> at
> org.apache.drill.exec.rpc.user.QueryResultHandler.resultArrived(QueryResultHandler.java:123)
> [drill-java-exec-1.16.0-SNAPSHOT.jar:1.16.0-SNAPSHOT]
> at
> org.apache.drill.exec.rpc.user.UserClient.handle(UserClient.java:422)
> [drill-java-exec-1.16.0-SNAPSHOT.jar:1.16.0-SNAPSHOT]
> at org.apache.drill.exec.rpc.user.UserClient.handle(UserClient.java:96)
> [drill-java-exec-1.16.0-SNAPSHOT.jar:1.16.0-SNAPSHOT]
> at
> org.apache.drill.exec.rpc.RpcBus$InboundHandler.decode(RpcBus.java:273)
> [drill-rpc-1.16.0-SNAPSHOT.jar:1.16.0-SNAPSHOT]
> at
> org.apache.drill.exec.rpc.RpcBus$InboundHandler.decode(RpcBus.java:243)
> [drill-rpc-1.16.0-SNAPSHOT.jar:1.16.0-SNAPSHOT]
> at
> io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:88)
> [netty-codec-4.0.48.Final.jar:4.0.48.Final]
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:356)
> [netty-transport-4.0.48.Final.jar:4.0.48.Final]
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:342)
> [netty-transport-4.0.48.Final.jar:4.0.48.Final]
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:335)
> [netty-transport-4.0.48.Final.jar:4.0.48.Final]
> at
> io.netty.handler.timeout.IdleStateHandler.channelRead(IdleStateHandler.java:287)
> [netty-handler-4.0.48.Final.jar:4.0.48.Final]
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:356)
> [netty-transport-4.0.48.Final.jar:4.0.48.Final]
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:342)
> [netty-transport-4.0.48.Final.jar:4.0.48.Final]
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:335)
> [netty-transport-4.0.48.Final.jar:4.0.48.Final]
> at
> io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:102)
> [netty-codec-4.0.48.Final.jar:4.0.48.Final]
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:356)
> [netty-transport-4.0.48.Final.jar:4.0.48.Final]
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:342)
> [netty-transport-4.0.48.Final.jar:4.0.48.Final]
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:335)
> [netty-transport-4.0.48.Final.jar:4.0.48.Final]
> at
> io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:312)
> [netty-codec-4.0.48.Final.jar:4.0.48.Final]
> at
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:286)
> [netty-codec-4.0.48.Final.jar:4.0.48.Final]
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:356)
> [netty-transport-4.0.48.Final.jar:4.0.48.Final]
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:342)
> [netty-transport-4.0.48.Final.jar:4.0.48.Final]
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:335)
> [netty-transport-4.0.48.Final.jar:4.0.48.Final]
> at
> io.netty.channel.ChannelInboundHandlerAdapter.channelRead(ChannelInboundHandlerAdapter.java:86)
>
[jira] [Assigned] (DRILL-7079) Drill can't query views from the S3 storage when plain authentication is enabled
[
https://issues.apache.org/jira/browse/DRILL-7079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arina Ielchiieva reassigned DRILL-7079:
---
Assignee: Bohdan Kazydub
> Drill can't query views from the S3 storage when plain authentication is
> enabled
>
>
> Key: DRILL-7079
> URL: https://issues.apache.org/jira/browse/DRILL-7079
> Project: Apache Drill
> Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Denys Ordynskiy
>Assignee: Bohdan Kazydub
>Priority: Major
>
> Enable plain authentication in Drill.
> Create the view on the S3 storage:
> create view s3.tmp.`testview` as select * from cp.`employee.json` limit 20;
> Try to select data from the created view:
> select * from s3.tmp.`testview`;
> *Actual result*:
> {noformat}
> 2019-02-27 17:01:09,202 [Client-1] INFO
> o.a.d.j.i.DrillCursor$ResultsListener - [#4] Query failed:
> org.apache.drill.common.exceptions.UserRemoteException: SYSTEM ERROR:
> IllegalArgumentException: A valid userName is expected
> Please, refer to logs for more information.
> [Error Id: 2271c3aa-6d09-4b51-a585-0e0e954b46eb on maprhost:31010]
> at
> org.apache.drill.exec.rpc.user.QueryResultHandler.resultArrived(QueryResultHandler.java:123)
> [drill-java-exec-1.16.0-SNAPSHOT.jar:1.16.0-SNAPSHOT]
> at
> org.apache.drill.exec.rpc.user.UserClient.handle(UserClient.java:422)
> [drill-java-exec-1.16.0-SNAPSHOT.jar:1.16.0-SNAPSHOT]
> at org.apache.drill.exec.rpc.user.UserClient.handle(UserClient.java:96)
> [drill-java-exec-1.16.0-SNAPSHOT.jar:1.16.0-SNAPSHOT]
> at
> org.apache.drill.exec.rpc.RpcBus$InboundHandler.decode(RpcBus.java:273)
> [drill-rpc-1.16.0-SNAPSHOT.jar:1.16.0-SNAPSHOT]
> at
> org.apache.drill.exec.rpc.RpcBus$InboundHandler.decode(RpcBus.java:243)
> [drill-rpc-1.16.0-SNAPSHOT.jar:1.16.0-SNAPSHOT]
> at
> io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:88)
> [netty-codec-4.0.48.Final.jar:4.0.48.Final]
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:356)
> [netty-transport-4.0.48.Final.jar:4.0.48.Final]
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:342)
> [netty-transport-4.0.48.Final.jar:4.0.48.Final]
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:335)
> [netty-transport-4.0.48.Final.jar:4.0.48.Final]
> at
> io.netty.handler.timeout.IdleStateHandler.channelRead(IdleStateHandler.java:287)
> [netty-handler-4.0.48.Final.jar:4.0.48.Final]
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:356)
> [netty-transport-4.0.48.Final.jar:4.0.48.Final]
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:342)
> [netty-transport-4.0.48.Final.jar:4.0.48.Final]
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:335)
> [netty-transport-4.0.48.Final.jar:4.0.48.Final]
> at
> io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:102)
> [netty-codec-4.0.48.Final.jar:4.0.48.Final]
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:356)
> [netty-transport-4.0.48.Final.jar:4.0.48.Final]
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:342)
> [netty-transport-4.0.48.Final.jar:4.0.48.Final]
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:335)
> [netty-transport-4.0.48.Final.jar:4.0.48.Final]
> at
> io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:312)
> [netty-codec-4.0.48.Final.jar:4.0.48.Final]
> at
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:286)
> [netty-codec-4.0.48.Final.jar:4.0.48.Final]
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:356)
> [netty-transport-4.0.48.Final.jar:4.0.48.Final]
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:342)
> [netty-transport-4.0.48.Final.jar:4.0.48.Final]
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:335)
> [netty-transport-4.0.48.Final.jar:4.0.48.Final]
> at
> io.netty.channel.ChannelInboundHandlerAdapter.channelRead(ChannelInboundHandlerAdapter.java:86)
> [netty-transport-4.0.48.Final.jar:4.0.48.Final]
>
[jira] [Updated] (DRILL-7079) Drill can't query views from the S3 storage when plain authentication is enabled
[
https://issues.apache.org/jira/browse/DRILL-7079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denys Ordynskiy updated DRILL-7079:
---
Affects Version/s: 1.15.0
> Drill can't query views from the S3 storage when plain authentication is
> enabled
>
>
> Key: DRILL-7079
> URL: https://issues.apache.org/jira/browse/DRILL-7079
> Project: Apache Drill
> Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Denys Ordynskiy
>Priority: Major
>
> Enable plain authentication in Drill.
> Create the view on the S3 storage:
> create view s3.tmp.`testview` as select * from cp.`employee.json` limit 20;
> Try to select data from the created view:
> select * from s3.tmp.`testview`;
> *Actual result*:
> {noformat}
> 2019-02-27 17:01:09,202 [Client-1] INFO
> o.a.d.j.i.DrillCursor$ResultsListener - [#4] Query failed:
> org.apache.drill.common.exceptions.UserRemoteException: SYSTEM ERROR:
> IllegalArgumentException: A valid userName is expected
> Please, refer to logs for more information.
> [Error Id: 2271c3aa-6d09-4b51-a585-0e0e954b46eb on maprhost:31010]
> at
> org.apache.drill.exec.rpc.user.QueryResultHandler.resultArrived(QueryResultHandler.java:123)
> [drill-java-exec-1.16.0-SNAPSHOT.jar:1.16.0-SNAPSHOT]
> at
> org.apache.drill.exec.rpc.user.UserClient.handle(UserClient.java:422)
> [drill-java-exec-1.16.0-SNAPSHOT.jar:1.16.0-SNAPSHOT]
> at org.apache.drill.exec.rpc.user.UserClient.handle(UserClient.java:96)
> [drill-java-exec-1.16.0-SNAPSHOT.jar:1.16.0-SNAPSHOT]
> at
> org.apache.drill.exec.rpc.RpcBus$InboundHandler.decode(RpcBus.java:273)
> [drill-rpc-1.16.0-SNAPSHOT.jar:1.16.0-SNAPSHOT]
> at
> org.apache.drill.exec.rpc.RpcBus$InboundHandler.decode(RpcBus.java:243)
> [drill-rpc-1.16.0-SNAPSHOT.jar:1.16.0-SNAPSHOT]
> at
> io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:88)
> [netty-codec-4.0.48.Final.jar:4.0.48.Final]
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:356)
> [netty-transport-4.0.48.Final.jar:4.0.48.Final]
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:342)
> [netty-transport-4.0.48.Final.jar:4.0.48.Final]
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:335)
> [netty-transport-4.0.48.Final.jar:4.0.48.Final]
> at
> io.netty.handler.timeout.IdleStateHandler.channelRead(IdleStateHandler.java:287)
> [netty-handler-4.0.48.Final.jar:4.0.48.Final]
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:356)
> [netty-transport-4.0.48.Final.jar:4.0.48.Final]
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:342)
> [netty-transport-4.0.48.Final.jar:4.0.48.Final]
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:335)
> [netty-transport-4.0.48.Final.jar:4.0.48.Final]
> at
> io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:102)
> [netty-codec-4.0.48.Final.jar:4.0.48.Final]
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:356)
> [netty-transport-4.0.48.Final.jar:4.0.48.Final]
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:342)
> [netty-transport-4.0.48.Final.jar:4.0.48.Final]
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:335)
> [netty-transport-4.0.48.Final.jar:4.0.48.Final]
> at
> io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:312)
> [netty-codec-4.0.48.Final.jar:4.0.48.Final]
> at
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:286)
> [netty-codec-4.0.48.Final.jar:4.0.48.Final]
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:356)
> [netty-transport-4.0.48.Final.jar:4.0.48.Final]
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:342)
> [netty-transport-4.0.48.Final.jar:4.0.48.Final]
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:335)
> [netty-transport-4.0.48.Final.jar:4.0.48.Final]
> at
> io.netty.channel.ChannelInboundHandlerAdapter.channelRead(ChannelInboundHandlerAdapter.java:86)
> [netty-transport-4.0.48.Final.jar:4.0.48.Final]
> at
>
[jira] [Created] (DRILL-7079) Drill can't query views from the S3 storage when plain authentication is enabled
Denys Ordynskiy created DRILL-7079:
--
Summary: Drill can't query views from the S3 storage when plain
authentication is enabled
Key: DRILL-7079
URL: https://issues.apache.org/jira/browse/DRILL-7079
Project: Apache Drill
Issue Type: Bug
Reporter: Denys Ordynskiy
Enable plain authentication in Drill.
Create the view on the S3 storage:
create view s3.tmp.`testview` as select * from cp.`employee.json` limit 20;
Try to select data from the created view:
select * from s3.tmp.`testview`;
*Actual result*:
{noformat}
2019-02-27 17:01:09,202 [Client-1] INFO o.a.d.j.i.DrillCursor$ResultsListener
- [#4] Query failed:
org.apache.drill.common.exceptions.UserRemoteException: SYSTEM ERROR:
IllegalArgumentException: A valid userName is expected
Please, refer to logs for more information.
[Error Id: 2271c3aa-6d09-4b51-a585-0e0e954b46eb on maprhost:31010]
at
org.apache.drill.exec.rpc.user.QueryResultHandler.resultArrived(QueryResultHandler.java:123)
[drill-java-exec-1.16.0-SNAPSHOT.jar:1.16.0-SNAPSHOT]
at
org.apache.drill.exec.rpc.user.UserClient.handle(UserClient.java:422)
[drill-java-exec-1.16.0-SNAPSHOT.jar:1.16.0-SNAPSHOT]
at org.apache.drill.exec.rpc.user.UserClient.handle(UserClient.java:96)
[drill-java-exec-1.16.0-SNAPSHOT.jar:1.16.0-SNAPSHOT]
at
org.apache.drill.exec.rpc.RpcBus$InboundHandler.decode(RpcBus.java:273)
[drill-rpc-1.16.0-SNAPSHOT.jar:1.16.0-SNAPSHOT]
at
org.apache.drill.exec.rpc.RpcBus$InboundHandler.decode(RpcBus.java:243)
[drill-rpc-1.16.0-SNAPSHOT.jar:1.16.0-SNAPSHOT]
at
io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:88)
[netty-codec-4.0.48.Final.jar:4.0.48.Final]
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:356)
[netty-transport-4.0.48.Final.jar:4.0.48.Final]
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:342)
[netty-transport-4.0.48.Final.jar:4.0.48.Final]
at
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:335)
[netty-transport-4.0.48.Final.jar:4.0.48.Final]
at
io.netty.handler.timeout.IdleStateHandler.channelRead(IdleStateHandler.java:287)
[netty-handler-4.0.48.Final.jar:4.0.48.Final]
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:356)
[netty-transport-4.0.48.Final.jar:4.0.48.Final]
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:342)
[netty-transport-4.0.48.Final.jar:4.0.48.Final]
at
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:335)
[netty-transport-4.0.48.Final.jar:4.0.48.Final]
at
io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:102)
[netty-codec-4.0.48.Final.jar:4.0.48.Final]
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:356)
[netty-transport-4.0.48.Final.jar:4.0.48.Final]
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:342)
[netty-transport-4.0.48.Final.jar:4.0.48.Final]
at
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:335)
[netty-transport-4.0.48.Final.jar:4.0.48.Final]
at
io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:312)
[netty-codec-4.0.48.Final.jar:4.0.48.Final]
at
io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:286)
[netty-codec-4.0.48.Final.jar:4.0.48.Final]
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:356)
[netty-transport-4.0.48.Final.jar:4.0.48.Final]
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:342)
[netty-transport-4.0.48.Final.jar:4.0.48.Final]
at
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:335)
[netty-transport-4.0.48.Final.jar:4.0.48.Final]
at
io.netty.channel.ChannelInboundHandlerAdapter.channelRead(ChannelInboundHandlerAdapter.java:86)
[netty-transport-4.0.48.Final.jar:4.0.48.Final]
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:356)
[netty-transport-4.0.48.Final.jar:4.0.48.Final]
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:342)
[netty-transport-4.0.48.Final.jar:4.0.48.Final]
at
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:335)
[jira] [Updated] (DRILL-7077) Add Function to Facilitate Time Series Analysis
[
https://issues.apache.org/jira/browse/DRILL-7077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arina Ielchiieva updated DRILL-7077:
Reviewer: Arina Ielchiieva
> Add Function to Facilitate Time Series Analysis
> ---
>
> Key: DRILL-7077
> URL: https://issues.apache.org/jira/browse/DRILL-7077
> Project: Apache Drill
> Issue Type: New Feature
>Affects Versions: 1.16.0
>Reporter: Charles Givre
>Assignee: Charles Givre
>Priority: Major
> Fix For: 1.16.0
>
>
> When analyzing time based data, you will often have to aggregate by time
> grains. While some time grains will be easy to calculate, others, such as
> quarter, can be quite difficult. These functions enable a user to quickly and
> easily aggregate data by various units of time. Usage is as follows:
> {code:java}
> SELECT
> FROM
> GROUP BY nearestDate(, {code}
> So let's say that a user wanted to count the number of hits on a web server
> per 15 minute, the query might look like this:
> {code:java}
> SELECT nearestDate(`eventDate`, '15MINUTE' ) AS eventDate,
> COUNT(*) AS hitCount
> FROM dfs.`log.httpd`
> GROUP BY nearestDate(`eventDate`, '15MINUTE'){code}
> Currently supports the following time units:
> * YEAR
> * QUARTER
> * MONTH
> * WEEK_SUNDAY
> * WEEK_MONDAY
> * DAY
> * HOUR
> * HALF_HOUR / 30MIN
> * QUARTER_HOUR / 15MIN
> * MINUTE
> * 30SECOND
> * 15SECOND
> * SECOND
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (DRILL-7038) Queries on partitioned columns scan the entire datasets
[
https://issues.apache.org/jira/browse/DRILL-7038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bohdan Kazydub updated DRILL-7038:
--
Labels: doc-impacting (was: )
> Queries on partitioned columns scan the entire datasets
> ---
>
> Key: DRILL-7038
> URL: https://issues.apache.org/jira/browse/DRILL-7038
> Project: Apache Drill
> Issue Type: Improvement
>Reporter: Bohdan Kazydub
>Assignee: Bohdan Kazydub
>Priority: Major
> Labels: doc-impacting
> Fix For: 1.16.0
>
>
> For tables with hive-style partitions like
> {code}
> /table/2018/Q1
> /table/2018/Q2
> /table/2019/Q1
> etc.
> {code}
> if any of the following queries is run:
> {code}
> select distinct dir0 from dfs.`/table`
> {code}
> {code}
> select dir0 from dfs.`/table` group by dir0
> {code}
> it will actually scan every single record in the table rather than just
> getting a list of directories at the dir0 level. This applies even when
> cached metadata is available. This is a big penalty especially as the
> datasets grow.
> To avoid such situations, a logical prune rule can be used to collect
> partition columns (`dir0`), either from metadata cache (if available) or
> group scan, and drop unnecessary files from being read. The rule will be
> applied on following conditions:
> 1) all queried columns are partitoin columns, and
> 2) either {{DISTINCT}} or {{GROUP BY}} operations are performed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (DRILL-7078) SqlLine: IOException: Resource temporarily unavailable
[
https://issues.apache.org/jira/browse/DRILL-7078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16785630#comment-16785630
]
Anton Gozhiy commented on DRILL-7078:
-
It is also reproduced if connect to Drill through jdbc (For example, using
DBeaver).
> SqlLine: IOException: Resource temporarily unavailable
> --
>
> Key: DRILL-7078
> URL: https://issues.apache.org/jira/browse/DRILL-7078
> Project: Apache Drill
> Issue Type: Bug
> Components: Client - CLI
>Affects Versions: 1.13.0
>Reporter: Vitalii Diravka
>Priority: Minor
> Fix For: Future
>
>
> The IOException is thrown from JLine in the process of using Drill WebUI with
> SPNEGO enabled.
> *drill-override.conf* content:
> {code:java}
> drill.exec: {
> cluster-id: "drillbits1",
> zk.connect: "localhost:2181",
> impersonation: {
>enabled: true,
>max_chained_user_hops: 3
> },
> security.user.auth: {
> enabled: true,
> packages += "org.apache.drill.exec.rpc.user.security",
> impl: "pam4j",
> pam_profiles: [ "sudo", "login" ]
> }
> drill.exec.http: {
> spnego.auth.principal:"HTTP/hostname@realm",
> spnego.auth.keytab:"path/to/keytab",
> auth.mechanisms: [“SPNEGO”, “FORM”]
> }
> }
> {code}
> {code:java}
> Apache Drill 1.16.0-SNAPSHOT
> "Got Drill?"
> sqlline> !connect jdbc:drill:zk=local [username] [password]
> 0: jdbc:drill:zk=local> select * from sys.boot where name like '%eng%' limit
> 2;
> +---+---+---+--+-+--+-+---++
> | name| kind |
> accessibleScopes | optionScope | status | num_val | string_val |
> bool_val | float_val |
> +---+---+---+--+-+--+-+---++
> | drill.exec.options.planner.identifier_max_length | LONG | BOOT
> | BOOT | BOOT| 1024 | null| null | null |
> +---+---+---+--+-+--+-+---++
> 1 row selected (2.268 seconds)
> {code}
> After referring to the Drill WebUI and opening any web page the following
> exception is thrown from Drill SqlLine:
> {code:java}
> 0: jdbc:drill:zk=local>
> java.io.IOError: java.io.IOException: Resource temporarily unavailable
> at
> org.jline.keymap.BindingReader.readCharacter(BindingReader.java:143)
> at org.jline.keymap.BindingReader.readBinding(BindingReader.java:110)
> at org.jline.keymap.BindingReader.readBinding(BindingReader.java:61)
> at
> org.jline.reader.impl.LineReaderImpl.readBinding(LineReaderImpl.java:786)
> at
> org.jline.reader.impl.LineReaderImpl.readLine(LineReaderImpl.java:558)
> at
> org.jline.reader.impl.LineReaderImpl.readLine(LineReaderImpl.java:443)
> at sqlline.SqlLine.begin(SqlLine.java:541)
> at sqlline.SqlLine.start(SqlLine.java:264)
> at sqlline.SqlLine.main(SqlLine.java:195)
> Caused by: java.io.IOException: Resource temporarily unavailable
> at java.io.FileInputStream.read0(Native Method)
> at java.io.FileInputStream.read(FileInputStream.java:207)
> at
> org.jline.terminal.impl.AbstractPty$PtyInputStream.read(AbstractPty.java:65)
> at
> org.jline.utils.NonBlockingInputStream.read(NonBlockingInputStream.java:62)
> at
> org.jline.utils.NonBlocking$NonBlockingInputStreamReader.read(NonBlocking.java:168)
> at org.jline.utils.NonBlockingReader.read(NonBlockingReader.java:57)
> at
> org.jline.keymap.BindingReader.readCharacter(BindingReader.java:133)
> ... 8 more
> 0: jdbc:drill:zk=local>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (DRILL-7078) SqlLine: IOException: Resource temporarily unavailable
[
https://issues.apache.org/jira/browse/DRILL-7078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arina Ielchiieva updated DRILL-7078:
Affects Version/s: (was: 1.14.0)
1.13.0
> SqlLine: IOException: Resource temporarily unavailable
> --
>
> Key: DRILL-7078
> URL: https://issues.apache.org/jira/browse/DRILL-7078
> Project: Apache Drill
> Issue Type: Bug
> Components: Client - CLI
>Affects Versions: 1.13.0
>Reporter: Vitalii Diravka
>Priority: Minor
> Fix For: Future
>
>
> The IOException is thrown from JLine in the process of using Drill WebUI with
> SPNEGO enabled.
> *drill-override.conf* content:
> {code:java}
> drill.exec: {
> cluster-id: "drillbits1",
> zk.connect: "localhost:2181",
> impersonation: {
>enabled: true,
>max_chained_user_hops: 3
> },
> security.user.auth: {
> enabled: true,
> packages += "org.apache.drill.exec.rpc.user.security",
> impl: "pam4j",
> pam_profiles: [ "sudo", "login" ]
> }
> drill.exec.http: {
> spnego.auth.principal:"HTTP/hostname@realm",
> spnego.auth.keytab:"path/to/keytab",
> auth.mechanisms: [“SPNEGO”, “FORM”]
> }
> }
> {code}
> {code:java}
> Apache Drill 1.16.0-SNAPSHOT
> "Got Drill?"
> sqlline> !connect jdbc:drill:zk=local [username] [password]
> 0: jdbc:drill:zk=local> select * from sys.boot where name like '%eng%' limit
> 2;
> +---+---+---+--+-+--+-+---++
> | name| kind |
> accessibleScopes | optionScope | status | num_val | string_val |
> bool_val | float_val |
> +---+---+---+--+-+--+-+---++
> | drill.exec.options.planner.identifier_max_length | LONG | BOOT
> | BOOT | BOOT| 1024 | null| null | null |
> +---+---+---+--+-+--+-+---++
> 1 row selected (2.268 seconds)
> {code}
> After referring to the Drill WebUI and opening any web page the following
> exception is thrown from Drill SqlLine:
> {code:java}
> 0: jdbc:drill:zk=local>
> java.io.IOError: java.io.IOException: Resource temporarily unavailable
> at
> org.jline.keymap.BindingReader.readCharacter(BindingReader.java:143)
> at org.jline.keymap.BindingReader.readBinding(BindingReader.java:110)
> at org.jline.keymap.BindingReader.readBinding(BindingReader.java:61)
> at
> org.jline.reader.impl.LineReaderImpl.readBinding(LineReaderImpl.java:786)
> at
> org.jline.reader.impl.LineReaderImpl.readLine(LineReaderImpl.java:558)
> at
> org.jline.reader.impl.LineReaderImpl.readLine(LineReaderImpl.java:443)
> at sqlline.SqlLine.begin(SqlLine.java:541)
> at sqlline.SqlLine.start(SqlLine.java:264)
> at sqlline.SqlLine.main(SqlLine.java:195)
> Caused by: java.io.IOException: Resource temporarily unavailable
> at java.io.FileInputStream.read0(Native Method)
> at java.io.FileInputStream.read(FileInputStream.java:207)
> at
> org.jline.terminal.impl.AbstractPty$PtyInputStream.read(AbstractPty.java:65)
> at
> org.jline.utils.NonBlockingInputStream.read(NonBlockingInputStream.java:62)
> at
> org.jline.utils.NonBlocking$NonBlockingInputStreamReader.read(NonBlocking.java:168)
> at org.jline.utils.NonBlockingReader.read(NonBlockingReader.java:57)
> at
> org.jline.keymap.BindingReader.readCharacter(BindingReader.java:133)
> ... 8 more
> 0: jdbc:drill:zk=local>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (DRILL-7078) SqlLine: IOException: Resource temporarily unavailable
[
https://issues.apache.org/jira/browse/DRILL-7078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arina Ielchiieva updated DRILL-7078:
Affects Version/s: (was: 1.15.0)
1.14.0
> SqlLine: IOException: Resource temporarily unavailable
> --
>
> Key: DRILL-7078
> URL: https://issues.apache.org/jira/browse/DRILL-7078
> Project: Apache Drill
> Issue Type: Bug
> Components: Client - CLI
>Affects Versions: 1.14.0
>Reporter: Vitalii Diravka
>Priority: Minor
> Fix For: Future
>
>
> The IOException is thrown from JLine in the process of using Drill WebUI with
> SPNEGO enabled.
> *drill-override.conf* content:
> {code:java}
> drill.exec: {
> cluster-id: "drillbits1",
> zk.connect: "localhost:2181",
> impersonation: {
>enabled: true,
>max_chained_user_hops: 3
> },
> security.user.auth: {
> enabled: true,
> packages += "org.apache.drill.exec.rpc.user.security",
> impl: "pam4j",
> pam_profiles: [ "sudo", "login" ]
> }
> drill.exec.http: {
> spnego.auth.principal:"HTTP/hostname@realm",
> spnego.auth.keytab:"path/to/keytab",
> auth.mechanisms: [“SPNEGO”, “FORM”]
> }
> }
> {code}
> {code:java}
> Apache Drill 1.16.0-SNAPSHOT
> "Got Drill?"
> sqlline> !connect jdbc:drill:zk=local [username] [password]
> 0: jdbc:drill:zk=local> select * from sys.boot where name like '%eng%' limit
> 2;
> +---+---+---+--+-+--+-+---++
> | name| kind |
> accessibleScopes | optionScope | status | num_val | string_val |
> bool_val | float_val |
> +---+---+---+--+-+--+-+---++
> | drill.exec.options.planner.identifier_max_length | LONG | BOOT
> | BOOT | BOOT| 1024 | null| null | null |
> +---+---+---+--+-+--+-+---++
> 1 row selected (2.268 seconds)
> {code}
> After referring to the Drill WebUI and opening any web page the following
> exception is thrown from Drill SqlLine:
> {code:java}
> 0: jdbc:drill:zk=local>
> java.io.IOError: java.io.IOException: Resource temporarily unavailable
> at
> org.jline.keymap.BindingReader.readCharacter(BindingReader.java:143)
> at org.jline.keymap.BindingReader.readBinding(BindingReader.java:110)
> at org.jline.keymap.BindingReader.readBinding(BindingReader.java:61)
> at
> org.jline.reader.impl.LineReaderImpl.readBinding(LineReaderImpl.java:786)
> at
> org.jline.reader.impl.LineReaderImpl.readLine(LineReaderImpl.java:558)
> at
> org.jline.reader.impl.LineReaderImpl.readLine(LineReaderImpl.java:443)
> at sqlline.SqlLine.begin(SqlLine.java:541)
> at sqlline.SqlLine.start(SqlLine.java:264)
> at sqlline.SqlLine.main(SqlLine.java:195)
> Caused by: java.io.IOException: Resource temporarily unavailable
> at java.io.FileInputStream.read0(Native Method)
> at java.io.FileInputStream.read(FileInputStream.java:207)
> at
> org.jline.terminal.impl.AbstractPty$PtyInputStream.read(AbstractPty.java:65)
> at
> org.jline.utils.NonBlockingInputStream.read(NonBlockingInputStream.java:62)
> at
> org.jline.utils.NonBlocking$NonBlockingInputStreamReader.read(NonBlocking.java:168)
> at org.jline.utils.NonBlockingReader.read(NonBlockingReader.java:57)
> at
> org.jline.keymap.BindingReader.readCharacter(BindingReader.java:133)
> ... 8 more
> 0: jdbc:drill:zk=local>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (DRILL-7078) SqlLine: IOException: Resource temporarily unavailable
[
https://issues.apache.org/jira/browse/DRILL-7078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arina Ielchiieva updated DRILL-7078:
Labels: (was: jline sqlline)
> SqlLine: IOException: Resource temporarily unavailable
> --
>
> Key: DRILL-7078
> URL: https://issues.apache.org/jira/browse/DRILL-7078
> Project: Apache Drill
> Issue Type: Bug
> Components: Client - CLI
>Affects Versions: 1.15.0
>Reporter: Vitalii Diravka
>Priority: Minor
> Fix For: Future
>
>
> The IOException is thrown from JLine in the process of using Drill WebUI with
> SPNEGO enabled.
> *drill-override.conf* content:
> {code:java}
> drill.exec: {
> cluster-id: "drillbits1",
> zk.connect: "localhost:2181",
> impersonation: {
>enabled: true,
>max_chained_user_hops: 3
> },
> security.user.auth: {
> enabled: true,
> packages += "org.apache.drill.exec.rpc.user.security",
> impl: "pam4j",
> pam_profiles: [ "sudo", "login" ]
> }
> drill.exec.http: {
> spnego.auth.principal:"HTTP/hostname@realm",
> spnego.auth.keytab:"path/to/keytab",
> auth.mechanisms: [“SPNEGO”, “FORM”]
> }
> }
> {code}
> {code:java}
> Apache Drill 1.16.0-SNAPSHOT
> "Got Drill?"
> sqlline> !connect jdbc:drill:zk=local [username] [password]
> 0: jdbc:drill:zk=local> select * from sys.boot where name like '%eng%' limit
> 2;
> +---+---+---+--+-+--+-+---++
> | name| kind |
> accessibleScopes | optionScope | status | num_val | string_val |
> bool_val | float_val |
> +---+---+---+--+-+--+-+---++
> | drill.exec.options.planner.identifier_max_length | LONG | BOOT
> | BOOT | BOOT| 1024 | null| null | null |
> +---+---+---+--+-+--+-+---++
> 1 row selected (2.268 seconds)
> {code}
> After referring to the Drill WebUI and opening any web page the following
> exception is thrown from Drill SqlLine:
> {code:java}
> 0: jdbc:drill:zk=local>
> java.io.IOError: java.io.IOException: Resource temporarily unavailable
> at
> org.jline.keymap.BindingReader.readCharacter(BindingReader.java:143)
> at org.jline.keymap.BindingReader.readBinding(BindingReader.java:110)
> at org.jline.keymap.BindingReader.readBinding(BindingReader.java:61)
> at
> org.jline.reader.impl.LineReaderImpl.readBinding(LineReaderImpl.java:786)
> at
> org.jline.reader.impl.LineReaderImpl.readLine(LineReaderImpl.java:558)
> at
> org.jline.reader.impl.LineReaderImpl.readLine(LineReaderImpl.java:443)
> at sqlline.SqlLine.begin(SqlLine.java:541)
> at sqlline.SqlLine.start(SqlLine.java:264)
> at sqlline.SqlLine.main(SqlLine.java:195)
> Caused by: java.io.IOException: Resource temporarily unavailable
> at java.io.FileInputStream.read0(Native Method)
> at java.io.FileInputStream.read(FileInputStream.java:207)
> at
> org.jline.terminal.impl.AbstractPty$PtyInputStream.read(AbstractPty.java:65)
> at
> org.jline.utils.NonBlockingInputStream.read(NonBlockingInputStream.java:62)
> at
> org.jline.utils.NonBlocking$NonBlockingInputStreamReader.read(NonBlocking.java:168)
> at org.jline.utils.NonBlockingReader.read(NonBlockingReader.java:57)
> at
> org.jline.keymap.BindingReader.readCharacter(BindingReader.java:133)
> ... 8 more
> 0: jdbc:drill:zk=local>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (DRILL-7078) SqlLine: IOException: Resource temporarily unavailable
[
https://issues.apache.org/jira/browse/DRILL-7078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16785602#comment-16785602
]
Anton Gozhiy commented on DRILL-7078:
-
There are simpler steps:
# Run Drill in embedded mode (no authentication settings are needed)
# Open the Web-UI (http://localhost:8047/)
# Run some query:
{code:java}
select * from cp.`tpch/nation.parquet`
{code}
Note: It is always reproducible the first time after starting Drill in embedded
mode. To reproduce it again, restart Drill or wait for some timeout (several
minutes).
> SqlLine: IOException: Resource temporarily unavailable
> --
>
> Key: DRILL-7078
> URL: https://issues.apache.org/jira/browse/DRILL-7078
> Project: Apache Drill
> Issue Type: Bug
> Components: Client - CLI
>Affects Versions: 1.15.0
>Reporter: Vitalii Diravka
>Priority: Minor
> Labels: jline, sqlline
> Fix For: Future
>
>
> The IOException is thrown from JLine in the process of using Drill WebUI with
> SPNEGO enabled.
> *drill-override.conf* content:
> {code:java}
> drill.exec: {
> cluster-id: "drillbits1",
> zk.connect: "localhost:2181",
> impersonation: {
>enabled: true,
>max_chained_user_hops: 3
> },
> security.user.auth: {
> enabled: true,
> packages += "org.apache.drill.exec.rpc.user.security",
> impl: "pam4j",
> pam_profiles: [ "sudo", "login" ]
> }
> drill.exec.http: {
> spnego.auth.principal:"HTTP/hostname@realm",
> spnego.auth.keytab:"path/to/keytab",
> auth.mechanisms: [“SPNEGO”, “FORM”]
> }
> }
> {code}
> {code:java}
> Apache Drill 1.16.0-SNAPSHOT
> "Got Drill?"
> sqlline> !connect jdbc:drill:zk=local [username] [password]
> 0: jdbc:drill:zk=local> select * from sys.boot where name like '%eng%' limit
> 2;
> +---+---+---+--+-+--+-+---++
> | name| kind |
> accessibleScopes | optionScope | status | num_val | string_val |
> bool_val | float_val |
> +---+---+---+--+-+--+-+---++
> | drill.exec.options.planner.identifier_max_length | LONG | BOOT
> | BOOT | BOOT| 1024 | null| null | null |
> +---+---+---+--+-+--+-+---++
> 1 row selected (2.268 seconds)
> {code}
> After referring to the Drill WebUI and opening any web page the following
> exception is thrown from Drill SqlLine:
> {code:java}
> 0: jdbc:drill:zk=local>
> java.io.IOError: java.io.IOException: Resource temporarily unavailable
> at
> org.jline.keymap.BindingReader.readCharacter(BindingReader.java:143)
> at org.jline.keymap.BindingReader.readBinding(BindingReader.java:110)
> at org.jline.keymap.BindingReader.readBinding(BindingReader.java:61)
> at
> org.jline.reader.impl.LineReaderImpl.readBinding(LineReaderImpl.java:786)
> at
> org.jline.reader.impl.LineReaderImpl.readLine(LineReaderImpl.java:558)
> at
> org.jline.reader.impl.LineReaderImpl.readLine(LineReaderImpl.java:443)
> at sqlline.SqlLine.begin(SqlLine.java:541)
> at sqlline.SqlLine.start(SqlLine.java:264)
> at sqlline.SqlLine.main(SqlLine.java:195)
> Caused by: java.io.IOException: Resource temporarily unavailable
> at java.io.FileInputStream.read0(Native Method)
> at java.io.FileInputStream.read(FileInputStream.java:207)
> at
> org.jline.terminal.impl.AbstractPty$PtyInputStream.read(AbstractPty.java:65)
> at
> org.jline.utils.NonBlockingInputStream.read(NonBlockingInputStream.java:62)
> at
> org.jline.utils.NonBlocking$NonBlockingInputStreamReader.read(NonBlocking.java:168)
> at org.jline.utils.NonBlockingReader.read(NonBlockingReader.java:57)
> at
> org.jline.keymap.BindingReader.readCharacter(BindingReader.java:133)
> ... 8 more
> 0: jdbc:drill:zk=local>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (DRILL-7078) SqlLine: IOException: Resource temporarily unavailable
Vitalii Diravka created DRILL-7078:
--
Summary: SqlLine: IOException: Resource temporarily unavailable
Key: DRILL-7078
URL: https://issues.apache.org/jira/browse/DRILL-7078
Project: Apache Drill
Issue Type: Bug
Components: Client - CLI
Affects Versions: 1.15.0
Reporter: Vitalii Diravka
Fix For: Future
The IOException is thrown from JLine in the process of using Drill WebUI with
SPNEGO enabled.
*drill-override.conf* content:
{code:java}
drill.exec: {
cluster-id: "drillbits1",
zk.connect: "localhost:2181",
impersonation: {
enabled: true,
max_chained_user_hops: 3
},
security.user.auth: {
enabled: true,
packages += "org.apache.drill.exec.rpc.user.security",
impl: "pam4j",
pam_profiles: [ "sudo", "login" ]
}
drill.exec.http: {
spnego.auth.principal:"HTTP/hostname@realm",
spnego.auth.keytab:"path/to/keytab",
auth.mechanisms: [“SPNEGO”, “FORM”]
}
}
{code}
{code:java}
Apache Drill 1.16.0-SNAPSHOT
"Got Drill?"
sqlline> !connect jdbc:drill:zk=local [username] [password]
0: jdbc:drill:zk=local> select * from sys.boot where name like '%eng%' limit 2;
+---+---+---+--+-+--+-+---++
| name| kind | accessibleScopes
| optionScope | status | num_val | string_val | bool_val | float_val |
+---+---+---+--+-+--+-+---++
| drill.exec.options.planner.identifier_max_length | LONG | BOOT
| BOOT | BOOT| 1024 | null| null | null |
+---+---+---+--+-+--+-+---++
1 row selected (2.268 seconds)
{code}
After referring to the Drill WebUI and opening any web page the following
exception is thrown from Drill SqlLine:
{code:java}
0: jdbc:drill:zk=local>
java.io.IOError: java.io.IOException: Resource temporarily unavailable
at org.jline.keymap.BindingReader.readCharacter(BindingReader.java:143)
at org.jline.keymap.BindingReader.readBinding(BindingReader.java:110)
at org.jline.keymap.BindingReader.readBinding(BindingReader.java:61)
at
org.jline.reader.impl.LineReaderImpl.readBinding(LineReaderImpl.java:786)
at
org.jline.reader.impl.LineReaderImpl.readLine(LineReaderImpl.java:558)
at
org.jline.reader.impl.LineReaderImpl.readLine(LineReaderImpl.java:443)
at sqlline.SqlLine.begin(SqlLine.java:541)
at sqlline.SqlLine.start(SqlLine.java:264)
at sqlline.SqlLine.main(SqlLine.java:195)
Caused by: java.io.IOException: Resource temporarily unavailable
at java.io.FileInputStream.read0(Native Method)
at java.io.FileInputStream.read(FileInputStream.java:207)
at
org.jline.terminal.impl.AbstractPty$PtyInputStream.read(AbstractPty.java:65)
at
org.jline.utils.NonBlockingInputStream.read(NonBlockingInputStream.java:62)
at
org.jline.utils.NonBlocking$NonBlockingInputStreamReader.read(NonBlocking.java:168)
at org.jline.utils.NonBlockingReader.read(NonBlockingReader.java:57)
at org.jline.keymap.BindingReader.readCharacter(BindingReader.java:133)
... 8 more
0: jdbc:drill:zk=local>
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (DRILL-6642) Update protocol-buffers version
[
https://issues.apache.org/jira/browse/DRILL-6642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16785567#comment-16785567
]
Anton Gozhiy commented on DRILL-6642:
-
Merged into master with commit 2c3e2de2f94fd3f21a11c22b7944b94953e4f397
> Update protocol-buffers version
> ---
>
> Key: DRILL-6642
> URL: https://issues.apache.org/jira/browse/DRILL-6642
> Project: Apache Drill
> Issue Type: Task
> Components: Tools, Build Test
>Affects Versions: 1.14.0
>Reporter: Vitalii Diravka
>Assignee: Anton Gozhiy
>Priority: Major
> Fix For: 1.16.0
>
>
> Currently Drill uses 2.5.0 {{protocol-buffers}} version.
> The last version is 3.6.0 in maven repo:
> [https://mvnrepository.com/artifact/com.google.protobuf/protobuf-java]
> The new version has a lot of useful enhancements, which can be used in Drill.
> One of them is using {{UNRECOGNIZED Enum NullValue}}, which can help to
> handle them in place of null values for {{ProtocolMessageEnum}} - DRILL-6639.
> Looks like the NullValue can be used instead of null returned from
> {{valueOf()}} (_or {{forNumber()}}, since {{valueOf()}} is deprecated in the
> newer protobuf version_):
>
> [https://developers.google.com/protocol-buffers/docs/reference/java/com/google/protobuf/NullValue]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
