[jira] [Updated] (DRILL-2961) Statement.setQueryTimeout() should throw a SQLException
[ https://issues.apache.org/jira/browse/DRILL-2961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Parth Chandra updated DRILL-2961: - Assignee: Daniel Barclay (Drill) (was: Parth Chandra) > Statement.setQueryTimeout() should throw a SQLException > --- > > Key: DRILL-2961 > URL: https://issues.apache.org/jira/browse/DRILL-2961 > Project: Apache Drill > Issue Type: Bug > Components: Client - JDBC >Affects Versions: 1.0.0 > Environment: RHEL 6.4 >Reporter: Kunal Khatua >Assignee: Daniel Barclay (Drill) > Fix For: 1.0.0 > > Attachments: DRILL-2961.1Prep.2.patch.txt, > DRILL-2961.1Prep.3.patch.txt, DRILL-2961.1Prep.4.patch.txt, > DRILL-2961.2Core.2.patch.txt, DRILL-2961.2Core.3.patch.txt, > DRILL-2961.2Core.4.patch.txt > > > When trying to set the timeout for a Drill Statement object, Drill does not > report any SQLException which makes the developer incorrectly believe that a > timeout has been set. > The operation should throw the exception: > java.sql.SQLException: Method not supported > at > org.apache.drill.jdbc.DrillStatement.setQueryTimeout(DrillStatement.java) > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DRILL-2961) Statement.setQueryTimeout() should throw a SQLException
[ https://issues.apache.org/jira/browse/DRILL-2961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14537673#comment-14537673 ] Parth Chandra commented on DRILL-2961: -- merged in commit a3ec52a > Statement.setQueryTimeout() should throw a SQLException > --- > > Key: DRILL-2961 > URL: https://issues.apache.org/jira/browse/DRILL-2961 > Project: Apache Drill > Issue Type: Bug > Components: Client - JDBC >Affects Versions: 1.0.0 > Environment: RHEL 6.4 >Reporter: Kunal Khatua >Assignee: Daniel Barclay (Drill) > Fix For: 1.0.0 > > Attachments: DRILL-2961.1Prep.2.patch.txt, > DRILL-2961.1Prep.3.patch.txt, DRILL-2961.1Prep.4.patch.txt, > DRILL-2961.2Core.2.patch.txt, DRILL-2961.2Core.3.patch.txt, > DRILL-2961.2Core.4.patch.txt > > > When trying to set the timeout for a Drill Statement object, Drill does not > report any SQLException which makes the developer incorrectly believe that a > timeout has been set. > The operation should throw the exception: > java.sql.SQLException: Method not supported > at > org.apache.drill.jdbc.DrillStatement.setQueryTimeout(DrillStatement.java) > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (DRILL-3023) Drill ODBC Connection not working - attached logs in the details
Murtaza created DRILL-3023: -- Summary: Drill ODBC Connection not working - attached logs in the details Key: DRILL-3023 URL: https://issues.apache.org/jira/browse/DRILL-3023 Project: Apache Drill Issue Type: Bug Components: Client - ODBC Affects Versions: 0.9.0 Reporter: Murtaza Assignee: Parth Chandra Priority: Critical Getting below error in the sqlline log file. Apache Drill 0.9 is installed on CentOS 64bit, embedded drillbits. Trying to access ODBC from Windows machine after installing ODBC 32bit & 64bit drivers, both have same errors. 2015-05-11 14:47:29,652 [UserServer-1] ERROR o.a.drill.exec.rpc.user.UserServer - Error 2845b981-804a-44d4-a9f1-88866f778c26 in Handling handshake request: RPC_VERSION_MISMATCH, Invalid rpc version. Expected 5, actual 3. 2015-05-11 14:47:29,653 [UserServer-1] ERROR o.a.d.exec.rpc.RpcExceptionHandler - Exception in pipeline. Closing channel between local /172.16.98.101:31010 and remote /10.16.17.114:61346 io.netty.handler.codec.DecoderException: org.apache.drill.exec.rpc.RpcException: Handshake request failed: Invalid rpc version. Expected 5, actual 3. at io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:99) [netty-codec-4.0.24.Final.jar:4.0.24.Final] at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:333) [netty-transport-4.0.24.Final.jar:4.0.24.Final] at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:319) [netty-transport-4.0.24.Final.jar:4.0.24.Final] at io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:103) [netty-codec-4.0.24.Final.jar:4.0.24.Final] at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:333) [netty-transport-4.0.24.Final.jar:4.0.24.Final] at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:319) [netty-transport-4.0.24.Final.jar:4.0.24.Final] at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:161) [netty-codec-4.0.24.Final.jar:4.0.24.Final] at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:333) [netty-transport-4.0.24.Final.jar:4.0.24.Final] at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:319) [netty-transport-4.0.24.Final.jar:4.0.24.Final] at io.netty.channel.ChannelInboundHandlerAdapter.channelRead(ChannelInboundHandlerAdapter.java:86) [netty-transport-4.0.24.Final.jar:4.0.24.Final] at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:333) [netty-transport-4.0.24.Final.jar:4.0.24.Final] at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:319) [netty-transport-4.0.24.Final.jar:4.0.24.Final] at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:787) [netty-transport-4.0.24.Final.jar:4.0.24.Final] at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:130) [netty-transport-4.0.24.Final.jar:4.0.24.Final] at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:511) [netty-transport-4.0.24.Final.jar:4.0.24.Final] at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:468) [netty-transport-4.0.24.Final.jar:4.0.24.Final] at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:382) [netty-transport-4.0.24.Final.jar:4.0.24.Final] at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:354) [netty-transport-4.0.24.Final.jar:4.0.24.Final] at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:116) [netty-common-4.0.24.Final.jar:4.0.24.Final] at java.lang.Thread.run(Thread.java:745) [na:1.7.0_60] Caused by: org.apache.drill.exec.rpc.RpcException: Handshake request failed: Invalid rpc version. Expected 5, actual 3. at org.apache.drill.exec.rpc.user.UserServer$1.consumeHandshake(UserServer.java:181) ~[drill-java-exec-0.9.0-rebuffed.jar:0.9.0] at org.apache.drill.exec.rpc.user.UserServer$1.consumeHandshake(UserServer.java:171) ~[drill-java-exec-0.9.0-rebuffed.jar:0.9.0] at org.apache.drill.exec.rpc.AbstractHandshakeHandler.decode(AbstractHandshakeHandler.java:57) ~[drill-java-exec-0.9.0-rebuffed.jar:0.9.0] at org.apache.drill.exec.rpc.AbstractHandshakeHandler.decode(AbstractHandshakeHandler.java:29) ~[drill-java-exec-0.9.0-rebuffed.jar:0.9.0] at io.netty.handler.codec.MessageToMessag
[jira] [Updated] (DRILL-2936) TPCH 4 and 18 SF100 hangs when hash agg is turned off
[
https://issues.apache.org/jira/browse/DRILL-2936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steven Phillips updated DRILL-2936:
---
Assignee: Jacques Nadeau (was: Steven Phillips)
> TPCH 4 and 18 SF100 hangs when hash agg is turned off
> -
>
> Key: DRILL-2936
> URL: https://issues.apache.org/jira/browse/DRILL-2936
> Project: Apache Drill
> Issue Type: Bug
> Components: Execution - Flow
>Reporter: Ramana Inukonda Nagaraj
>Assignee: Jacques Nadeau
>Priority: Critical
> Fix For: 1.0.0
>
> Attachments: DRILL-2936.patch, Screen Shot 2015-05-01 at 2.40.36
> PM.png
>
>
> sys options:
> {code}
> 0: jdbc:drill:schema=dfs.drillTestDirTpch100P> alter system set
> `planner.memory.max_query_memory_per_node` = 29205777612;
> 0: jdbc:drill:schema=dfs.drillTestDirTpch100P> alter system set
> `planner.enable_hashjoin`=false;
> 0: jdbc:drill:schema=dfs.drillTestDirTpch100P> alter system set
> `planner.enable_hashagg`=false;
> {code}
> On executing TPCH 04 query hangs. From the profiles page does not look like
> any fragments are making progress, the last progress time stamps were
> sometime back.
> Attached is the logical plan.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DRILL-2936) TPCH 4 and 18 SF100 hangs when hash agg is turned off
[
https://issues.apache.org/jira/browse/DRILL-2936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14537866#comment-14537866
]
Steven Phillips commented on DRILL-2936:
Created reviewboard https://reviews.apache.org/r/34037/
> TPCH 4 and 18 SF100 hangs when hash agg is turned off
> -
>
> Key: DRILL-2936
> URL: https://issues.apache.org/jira/browse/DRILL-2936
> Project: Apache Drill
> Issue Type: Bug
> Components: Execution - Flow
>Reporter: Ramana Inukonda Nagaraj
>Assignee: Steven Phillips
>Priority: Critical
> Fix For: 1.0.0
>
> Attachments: DRILL-2936.patch, Screen Shot 2015-05-01 at 2.40.36
> PM.png
>
>
> sys options:
> {code}
> 0: jdbc:drill:schema=dfs.drillTestDirTpch100P> alter system set
> `planner.memory.max_query_memory_per_node` = 29205777612;
> 0: jdbc:drill:schema=dfs.drillTestDirTpch100P> alter system set
> `planner.enable_hashjoin`=false;
> 0: jdbc:drill:schema=dfs.drillTestDirTpch100P> alter system set
> `planner.enable_hashagg`=false;
> {code}
> On executing TPCH 04 query hangs. From the profiles page does not look like
> any fragments are making progress, the last progress time stamps were
> sometime back.
> Attached is the logical plan.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DRILL-2936) TPCH 4 and 18 SF100 hangs when hash agg is turned off
[
https://issues.apache.org/jira/browse/DRILL-2936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steven Phillips updated DRILL-2936:
---
Attachment: DRILL-2936.patch
> TPCH 4 and 18 SF100 hangs when hash agg is turned off
> -
>
> Key: DRILL-2936
> URL: https://issues.apache.org/jira/browse/DRILL-2936
> Project: Apache Drill
> Issue Type: Bug
> Components: Execution - Flow
>Reporter: Ramana Inukonda Nagaraj
>Assignee: Steven Phillips
>Priority: Critical
> Fix For: 1.0.0
>
> Attachments: DRILL-2936.patch, Screen Shot 2015-05-01 at 2.40.36
> PM.png
>
>
> sys options:
> {code}
> 0: jdbc:drill:schema=dfs.drillTestDirTpch100P> alter system set
> `planner.memory.max_query_memory_per_node` = 29205777612;
> 0: jdbc:drill:schema=dfs.drillTestDirTpch100P> alter system set
> `planner.enable_hashjoin`=false;
> 0: jdbc:drill:schema=dfs.drillTestDirTpch100P> alter system set
> `planner.enable_hashagg`=false;
> {code}
> On executing TPCH 04 query hangs. From the profiles page does not look like
> any fragments are making progress, the last progress time stamps were
> sometime back.
> Attached is the logical plan.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (DRILL-3024) UserException should have a getErrorType() method
Deneche A. Hakim created DRILL-3024: --- Summary: UserException should have a getErrorType() method Key: DRILL-3024 URL: https://issues.apache.org/jira/browse/DRILL-3024 Project: Apache Drill Issue Type: Improvement Reporter: Deneche A. Hakim Assignee: Deneche A. Hakim Priority: Minor Fix For: 1.1.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DRILL-3015) Can't connect to Squirrel using JDBC
[ https://issues.apache.org/jira/browse/DRILL-3015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14538274#comment-14538274 ] Daniel Barclay (Drill) commented on DRILL-3015: --- > Any updates on this issue? Appreciate your response. You'll have to be patient; we're in the middle of getting the 1.0 release out. Have you been able to connect using SQLLine? (If so, which JDBC URL(s) worked?) Can you get any more of an error message than "Cannot open SQL connection" out of Squirrel (so we can see what error Squirrel is getting from Drill's JDBC driver)? Does Squirrel have a verbose mode, or logging? Related to that, I happen to be working on DRILL-3020. Once that's in, Squirrel's "Cannot open SQL connection" message might include more text, which might indicate more about the problem. Daniel > Can't connect to Squirrel using JDBC > > > Key: DRILL-3015 > URL: https://issues.apache.org/jira/browse/DRILL-3015 > Project: Apache Drill > Issue Type: Bug > Components: Client - JDBC >Affects Versions: 0.9.0 >Reporter: Murtaza >Assignee: Daniel Barclay (Drill) >Priority: Blocker > > Please suggest me what jdbc url to use with Squirrel. I have installed Apache > Drill 0.9 on standalone macbook. I had given all types of jdbc url like below > jdbc:drill:zk=192.168.1.7:5181/drill/drillbits1;schema=dfs > jdbc:drill:zk=192.168.1.7:2181/drill/drillbits1;schema=dfs > jdbc:drill:zk=KWTLT01407.local:5181/drill/drillbits1;schema=dfs > jdbc:drill:zk=KWTLT01407.local:2181/drill/drillbits1;schema=dfs > All is giving me error in Squirrel stating "Cannot open SQL connection". > Please suggest me how to use JDBC to connect to Apache Drill installed on > standalone machines. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DRILL-3023) Drill ODBC Connection not working - attached logs in the details
[ https://issues.apache.org/jira/browse/DRILL-3023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14538273#comment-14538273 ] Parth Chandra commented on DRILL-3023: -- Hi Murtaza, You have a clear mismatch between the Drill client(s) and the server. Can you confirm the sqlline client (and the ODBC driver) you are using are the ones that come with 0.9? Parth > Drill ODBC Connection not working - attached logs in the details > > > Key: DRILL-3023 > URL: https://issues.apache.org/jira/browse/DRILL-3023 > Project: Apache Drill > Issue Type: Bug > Components: Client - ODBC >Affects Versions: 0.9.0 >Reporter: Murtaza >Assignee: Parth Chandra >Priority: Critical > > Getting below error in the sqlline log file. > Apache Drill 0.9 is installed on CentOS 64bit, embedded drillbits. Trying to > access ODBC from Windows machine after installing ODBC 32bit & 64bit drivers, > both have same errors. > 2015-05-11 14:47:29,652 [UserServer-1] ERROR > o.a.drill.exec.rpc.user.UserServer - Error > 2845b981-804a-44d4-a9f1-88866f778c26 in Handling handshake request: > RPC_VERSION_MISMATCH, Invalid rpc version. Expected 5, actual 3. > 2015-05-11 14:47:29,653 [UserServer-1] ERROR > o.a.d.exec.rpc.RpcExceptionHandler - Exception in pipeline. Closing channel > between local /172.16.98.101:31010 and remote /10.16.17.114:61346 > io.netty.handler.codec.DecoderException: > org.apache.drill.exec.rpc.RpcException: Handshake request failed: Invalid rpc > version. Expected 5, actual 3. > at > io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:99) > [netty-codec-4.0.24.Final.jar:4.0.24.Final] > at > io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:333) > [netty-transport-4.0.24.Final.jar:4.0.24.Final] > at > io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:319) > [netty-transport-4.0.24.Final.jar:4.0.24.Final] > at > io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:103) > [netty-codec-4.0.24.Final.jar:4.0.24.Final] > at > io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:333) > [netty-transport-4.0.24.Final.jar:4.0.24.Final] > at > io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:319) > [netty-transport-4.0.24.Final.jar:4.0.24.Final] > at > io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:161) > [netty-codec-4.0.24.Final.jar:4.0.24.Final] > at > io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:333) > [netty-transport-4.0.24.Final.jar:4.0.24.Final] > at > io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:319) > [netty-transport-4.0.24.Final.jar:4.0.24.Final] > at > io.netty.channel.ChannelInboundHandlerAdapter.channelRead(ChannelInboundHandlerAdapter.java:86) > [netty-transport-4.0.24.Final.jar:4.0.24.Final] > at > io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:333) > [netty-transport-4.0.24.Final.jar:4.0.24.Final] > at > io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:319) > [netty-transport-4.0.24.Final.jar:4.0.24.Final] > at > io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:787) > [netty-transport-4.0.24.Final.jar:4.0.24.Final] > at > io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:130) > [netty-transport-4.0.24.Final.jar:4.0.24.Final] > at > io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:511) > [netty-transport-4.0.24.Final.jar:4.0.24.Final] > at > io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:468) > [netty-transport-4.0.24.Final.jar:4.0.24.Final] > at > io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:382) > [netty-transport-4.0.24.Final.jar:4.0.24.Final] > at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:354) > [netty-transport-4.0.24.Final.jar:4.0.24.Final] > at > io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:116) > [netty-common-4.0.24.Final.jar:4.0.24.Final] > at java.lang.Thread.run(Thread.java:745) [na:1.7.0_60] > Caused by: org.apache.drill.exec.rpc.RpcException: Handshake request failed: > Invalid rpc version. Expected 5, actual 3. > at > org.apache.dri
[jira] [Updated] (DRILL-2929) Join query does not return results/error/exception, appears to be hung
[
https://issues.apache.org/jira/browse/DRILL-2929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sean Hsuan-Yi Chu updated DRILL-2929:
-
Assignee: Sean Hsuan-Yi Chu (was: Jinfeng Ni)
> Join query does not return results/error/exception, appears to be hung
> --
>
> Key: DRILL-2929
> URL: https://issues.apache.org/jira/browse/DRILL-2929
> Project: Apache Drill
> Issue Type: Bug
> Components: Query Planning & Optimization
>Affects Versions: 0.9.0
> Environment: f5b0f4928d9c8c47c145a179c52ba3933d85c0b4 | DRILL-1502:
> Can't connect to mongo when requiring auth | 29.04.2015 @ 11:22:41 EDT |
> Unknown | 29.04.2015 @ 14:44:10 EDT |
>Reporter: Khurram Faraaz
>Assignee: Sean Hsuan-Yi Chu
> Fix For: 1.0.0
>
>
> multi way equi join query hangs on rpm version based on 29th. Explain plan
> does not return anything, web UI shows query as PENDING state. Test was run
> on 4 node cluster on CentOS. There are no errors/exceptions reported in
> drillbit.log
> Hanging query is,
> {code}
> 0: jdbc:drill:> select bi.columns[0], ci.columns[0], di.columns[0],
> fi.columns[0], ini.columns[0], vi.columns[0]
> . . . . . . . > from `bgint_f.csv` bi,
> . . . . . . . > `char_f.csv` ci,
> . . . . . . . > `dbl_f.csv` di,
> . . . . . . . > `float_f.csv` fi,
> . . . . . . . > `int_f.csv` ini,
> . . . . . . . > `vchar_f.csv` vi
> . . . . . . . > where bi.columns[0] = ci.columns[0]
> . . . . . . . > and di.columns[0] = fi.columns[0]
> . . . . . . . > and ini.columns[0] = vi.columns[0]
> . . . . . . . > and ci.columns[0] = di.columns[0]
> . . . . . . . > and fi.columns[0] = ini.columns[0]
> . . . . . . . > and ci.columns[0] = ini.columns[0];
> {code}
> Data used in test is
> {code}
> [root@centos-04 join_hang]# hadoop fs -cat /tmp/bgint_f.csv
> 1
> 2
> 0
> -1
> 100
> 65535
> 100
> 13
> 19
> 17
> 11
> 1010101
> 999
> [root@centos-04 join_hang]# hadoop fs -cat /tmp/char_f.csv
> 1
> 2
> 3
> 4
> 5
> 6
> 7
> 8
> 9
> 0
> [root@centos-04 join_hang]# hadoop fs -cat /tmp/dbl_f.csv
> 123.45
> 11.98
> 12345.39
> 1.1
> 1.0
> 0.0
> -1.0
> 1.99
> 9.99
> [root@centos-04 join_hang]# hadoop fs -cat /tmp/float_f.csv
> 1.1
> 1.234
> 1234.19
> 13.19
> 1.0
> -1.0
> 0.0
> .98
> .99
> [root@centos-04 join_hang]# hadoop fs -cat /tmp/int_f.csv
> 1
> 0
> -1
> 65535
> 1234567
> 100
> 101010
> 1
> 100
> 13
> 19
> 17
> [root@centos-04 join_hang]# hadoop fs -cat /tmp/vchar_f.csv
> 12345
> 1
> 0
> -1
> 20
> 100
> 65535
> 13
> 19
> 17
> 1
> 10101
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (DRILL-3025) Tibco Spotfire Server - JDBC - Configuration Document
Andries Engelbrecht created DRILL-3025: -- Summary: Tibco Spotfire Server - JDBC - Configuration Document Key: DRILL-3025 URL: https://issues.apache.org/jira/browse/DRILL-3025 Project: Apache Drill Issue Type: Improvement Components: Documentation Affects Versions: 1.0.0 Reporter: Andries Engelbrecht Assignee: Bridget Bevens TSS Configuration document - JDBC -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-3025) Tibco Spotfire Server - JDBC - Configuration Document
[ https://issues.apache.org/jira/browse/DRILL-3025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andries Engelbrecht updated DRILL-3025: --- Attachment: Tibco Spotfire Server 6.0 Drill Configuration.docx > Tibco Spotfire Server - JDBC - Configuration Document > - > > Key: DRILL-3025 > URL: https://issues.apache.org/jira/browse/DRILL-3025 > Project: Apache Drill > Issue Type: Improvement > Components: Documentation >Affects Versions: 1.0.0 >Reporter: Andries Engelbrecht >Assignee: Bridget Bevens > Attachments: Tibco Spotfire Server 6.0 Drill Configuration.docx > > > TSS Configuration document - JDBC -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-1970) Hive views must not be listed with the show tables command
[ https://issues.apache.org/jira/browse/DRILL-1970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Altekruse updated DRILL-1970: --- Fix Version/s: (was: 1.0.0) 1.1.0 > Hive views must not be listed with the show tables command > -- > > Key: DRILL-1970 > URL: https://issues.apache.org/jira/browse/DRILL-1970 > Project: Apache Drill > Issue Type: Bug > Components: Storage - Hive >Reporter: Abhishek Girish >Assignee: Jason Altekruse > Fix For: 1.1.0 > > Attachments: DRILL-1970.1.patch.txt, DRILL-1970.2.patch.txt > > > This is related to DRILL-1969. > Until Drill can support querying of Hive Views, hive views metadata must not > be visible upon issuing the "show tables" command. > > use hive; > +++ > | ok | summary | > +++ > | true | Default schema changed to 'hive' | > +++ > Currently Observed: > > show tables ; > +--++ > | TABLE_SCHEMA | TABLE_NAME | > +--++ > | hive.default | table1 | > | hive.default | table2 | > | hive.default | table1_view1 | > | hive.default | table2_view1 | > ... > +--++ > Expected: > > show tables ; > +--++ > | TABLE_SCHEMA | TABLE_NAME | > +--++ > | hive.default | table1 | > | hive.default | table2 | > +--++ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-2022) Parquet engine falls back to "new" Parquet reader unnecessarily
[ https://issues.apache.org/jira/browse/DRILL-2022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Altekruse updated DRILL-2022: --- Fix Version/s: (was: 1.0.0) 1.1.0 > Parquet engine falls back to "new" Parquet reader unnecessarily > --- > > Key: DRILL-2022 > URL: https://issues.apache.org/jira/browse/DRILL-2022 > Project: Apache Drill > Issue Type: Improvement > Components: Storage - Parquet >Affects Versions: 0.8.0 >Reporter: Adam Gilmore >Assignee: Jason Altekruse >Priority: Minor > Fix For: 1.1.0 > > Attachments: DRILL-2022.1.patch.txt, DRILL-2022.2.patch.txt > > > The Parquet engine falls back to the "new" Parquet reader whenever a Parquet > file that is "complex" (i.e. not purely primitive types) is found. > The engine should still use the faster reader when all the projected columns > are primitive types and only fall back to the other reader when columns > containing complex types are selected. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-2764) REST API should return exception details on error
[ https://issues.apache.org/jira/browse/DRILL-2764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Venki Korukanti updated DRILL-2764: --- Fix Version/s: (was: 1.0.0) 1.1.0 > REST API should return exception details on error > - > > Key: DRILL-2764 > URL: https://issues.apache.org/jira/browse/DRILL-2764 > Project: Apache Drill > Issue Type: Improvement > Components: Client - HTTP >Affects Versions: 0.8.0 >Reporter: Adam Gilmore >Assignee: Venki Korukanti >Priority: Minor > Fix For: 1.1.0 > > Attachments: DRILL-2764.1.patch.txt > > > Currently, if an exception occurs via the REST API (e.g. your query is > invalid or fails to execute for any reason), the server returns a 500 status > code with a standard error page. > We should be getting the full details of the exception that occurred so we > can log the results and have better insight into the success of the query. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-2536) Peak Mem column in the profile page displays 0 when value is less than 1MB
[ https://issues.apache.org/jira/browse/DRILL-2536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Krystal updated DRILL-2536: --- Labels: no_verified_test (was: ) > Peak Mem column in the profile page displays 0 when value is less than 1MB > -- > > Key: DRILL-2536 > URL: https://issues.apache.org/jira/browse/DRILL-2536 > Project: Apache Drill > Issue Type: Bug > Components: Client - HTTP >Affects Versions: 0.9.0 >Reporter: Krystal >Assignee: Jason Altekruse > Labels: no_verified_test > Fix For: 1.0.0 > > Attachments: DRILL-2536.1.patch.txt > > > git.commit.id=4d398edf87d2ec6fab6c552b1f5a33fb31b955bc > For the "Peak Mem" column in the Query and Planning page, the value is > displayed as 0 when the actual value is less than 1MB. We should display > more granular value for this especially for smaller jobs; maybe display up to > 2 or 3 digits after the decimal. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-3011) Make Prel.copy abstract and implement for all nodes
[ https://issues.apache.org/jira/browse/DRILL-3011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mehant Baid updated DRILL-3011: --- Fix Version/s: (was: 1.0.0) 1.1.0 > Make Prel.copy abstract and implement for all nodes > --- > > Key: DRILL-3011 > URL: https://issues.apache.org/jira/browse/DRILL-3011 > Project: Apache Drill > Issue Type: Bug > Components: Query Planning & Optimization >Reporter: Jacques Nadeau >Assignee: Mehant Baid > Fix For: 1.1.0 > > > There is currently an issue where inherit copy() from BaseRelNode. Late in > our planning process, we attempt to uniqify the graph to ensure that no nodes > have the same identifier. However, the fact that we aren't implementing copy > means that we have issues uniqifying. We should add the following method to > the Prel interface and then implement all required implementations. > public abstract Prel copy(RelTraitSet paramRelTraitSet, List > paramList); -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (DRILL-1980) Create table with a Cast to interval day results in a file which cannot be read
[
https://issues.apache.org/jira/browse/DRILL-1980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mehant Baid reassigned DRILL-1980:
--
Assignee: Mehant Baid (was: Jason Altekruse)
> Create table with a Cast to interval day results in a file which cannot be
> read
> ---
>
> Key: DRILL-1980
> URL: https://issues.apache.org/jira/browse/DRILL-1980
> Project: Apache Drill
> Issue Type: Bug
> Components: Storage - Parquet
>Affects Versions: 0.7.0
>Reporter: Ramana Inukonda Nagaraj
>Assignee: Mehant Baid
> Fix For: 1.0.0
>
> Attachments: alltypes.json, parquet_all_types.parquet
>
>
> Created a parquet file from a json file with all types listed in it.
> {code}
> 0: jdbc:drill:> CREATE TABLE parquet_all_types AS SELECT cast( INT_col as
> int) INT_col,cast( BIGINT_col as bigint) BIGINT_col,cast( DECIMAL9_col as
> decimal) DECIMAL9_col,cast( DECIMAL18_col as decimal(18,9))
> DECIMAL18_col,cast( DECIMAL28SPARSE_col as decimal(28, 14))
> DECIMAL28SPARSE_col,cast( DECIMAL38SPARSE_col as decimal(38, 19))
> DECIMAL38SPARSE_col,cast( DATE_col as date) DATE_col,cast( TIME_col as time)
> TIME_col,cast( TIMESTAMP_col as timestamp) TIMESTAMP_col,cast( FLOAT4_col as
> float) FLOAT4_col,cast( FLOAT8_col as double) FLOAT8_col,cast( BIT_col as
> boolean) BIT_col,cast( VARCHAR_col as varchar(65000)) VARCHAR_col,cast(
> VAR16CHAR_col as varchar(65000)) VAR16CHAR_col,cast( VARBINARY_col as
> varbinary(65000)) VARBINARY_col,cast( INTERVALYEAR_col as interval year)
> INTERVALYEAR_col,cast( INTERVALDAY_col as interval day) INTERVALDAY_col FROM
> `/user/root/alltypes.json`;
> ++---+
> | Fragment | Number of records written |
> ++---+
> | 0_0| 8 |
> ++---+
> 1 row selected (0.595 seconds)
> {code}
> Tried reading created parquet file from drill. Fails with
> {code}
> 0: jdbc:drill:> explain plan for select * from
> `/parquet_all_types/0_0_0.parquet`;
> Query failed: Query failed: Unexpected exception during fragment
> initialization: Internal error: Error while applying rule DrillTableRule,
> args [rel#6060:EnumerableTableAccessRel.ENUMERABLE.ANY([]).[](table=[dfs,
> root, /parquet_all_types/0_0_0.parquet])]
> Error: exception while executing query: Failure while executing query.
> (state=,code=0)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DRILL-1980) Create table with a Cast to interval day results in a file which cannot be read
[
https://issues.apache.org/jira/browse/DRILL-1980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mehant Baid updated DRILL-1980:
---
Fix Version/s: (was: 1.2.0)
1.0.0
> Create table with a Cast to interval day results in a file which cannot be
> read
> ---
>
> Key: DRILL-1980
> URL: https://issues.apache.org/jira/browse/DRILL-1980
> Project: Apache Drill
> Issue Type: Bug
> Components: Storage - Parquet
>Affects Versions: 0.7.0
>Reporter: Ramana Inukonda Nagaraj
>Assignee: Mehant Baid
> Fix For: 1.0.0
>
> Attachments: alltypes.json, parquet_all_types.parquet
>
>
> Created a parquet file from a json file with all types listed in it.
> {code}
> 0: jdbc:drill:> CREATE TABLE parquet_all_types AS SELECT cast( INT_col as
> int) INT_col,cast( BIGINT_col as bigint) BIGINT_col,cast( DECIMAL9_col as
> decimal) DECIMAL9_col,cast( DECIMAL18_col as decimal(18,9))
> DECIMAL18_col,cast( DECIMAL28SPARSE_col as decimal(28, 14))
> DECIMAL28SPARSE_col,cast( DECIMAL38SPARSE_col as decimal(38, 19))
> DECIMAL38SPARSE_col,cast( DATE_col as date) DATE_col,cast( TIME_col as time)
> TIME_col,cast( TIMESTAMP_col as timestamp) TIMESTAMP_col,cast( FLOAT4_col as
> float) FLOAT4_col,cast( FLOAT8_col as double) FLOAT8_col,cast( BIT_col as
> boolean) BIT_col,cast( VARCHAR_col as varchar(65000)) VARCHAR_col,cast(
> VAR16CHAR_col as varchar(65000)) VAR16CHAR_col,cast( VARBINARY_col as
> varbinary(65000)) VARBINARY_col,cast( INTERVALYEAR_col as interval year)
> INTERVALYEAR_col,cast( INTERVALDAY_col as interval day) INTERVALDAY_col FROM
> `/user/root/alltypes.json`;
> ++---+
> | Fragment | Number of records written |
> ++---+
> | 0_0| 8 |
> ++---+
> 1 row selected (0.595 seconds)
> {code}
> Tried reading created parquet file from drill. Fails with
> {code}
> 0: jdbc:drill:> explain plan for select * from
> `/parquet_all_types/0_0_0.parquet`;
> Query failed: Query failed: Unexpected exception during fragment
> initialization: Internal error: Error while applying rule DrillTableRule,
> args [rel#6060:EnumerableTableAccessRel.ENUMERABLE.ANY([]).[](table=[dfs,
> root, /parquet_all_types/0_0_0.parquet])]
> Error: exception while executing query: Failure while executing query.
> (state=,code=0)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (DRILL-2536) Peak Mem column in the profile page displays 0 when value is less than 1MB
[ https://issues.apache.org/jira/browse/DRILL-2536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Krystal closed DRILL-2536. -- git.commit.id.abbrev=4689468 Verified that the peak memory is now displaying values for KB. > Peak Mem column in the profile page displays 0 when value is less than 1MB > -- > > Key: DRILL-2536 > URL: https://issues.apache.org/jira/browse/DRILL-2536 > Project: Apache Drill > Issue Type: Bug > Components: Client - HTTP >Affects Versions: 0.9.0 >Reporter: Krystal >Assignee: Jason Altekruse > Labels: no_verified_test > Fix For: 1.0.0 > > Attachments: DRILL-2536.1.patch.txt > > > git.commit.id=4d398edf87d2ec6fab6c552b1f5a33fb31b955bc > For the "Peak Mem" column in the Query and Planning page, the value is > displayed as 0 when the actual value is less than 1MB. We should display > more granular value for this especially for smaller jobs; maybe display up to > 2 or 3 digits after the decimal. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-3018) Queries with scalar aggregate and non equality (non correlated) fail to plan
[
https://issues.apache.org/jira/browse/DRILL-3018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinfeng Ni updated DRILL-3018:
--
Attachment: 0001-DRILL-3018-Fix-CanNotPlan-for-nestLoop-left-join-cau.patch
> Queries with scalar aggregate and non equality (non correlated) fail to plan
> -
>
> Key: DRILL-3018
> URL: https://issues.apache.org/jira/browse/DRILL-3018
> Project: Apache Drill
> Issue Type: Bug
> Components: Query Planning & Optimization
>Affects Versions: 1.0.0
>Reporter: Victoria Markman
>Assignee: Jinfeng Ni
> Fix For: 1.0.0
>
> Attachments:
> 0001-DRILL-3018-Fix-CanNotPlan-for-nestLoop-left-join-cau.patch, tables.tar
>
>
> This is a regression.
> Both queries worked and returned correct result with May 7 build
> (mapr-drill-1.0.0.31658-1.noarch.rpm)
> Running with the latest build, I got these two failures:
> {code}
> select * from j2 where c_integer > (select min(c_bigint) from j7 where
> c_boolean is null)
> Failed with exception
> java.sql.SQLException: SYSTEM ERROR:
> org.apache.drill.exec.work.foreman.UnsupportedRelOperatorException: This
> query cannot be planned possibly due to either a cartesian join or an
> inequality
> select * from j2 where c_float < (select min(c_float) from j6 where c_boolean
> is null )
> Failed with exception
> java.sql.SQLException: SYSTEM ERROR:
> org.apache.drill.exec.work.foreman.UnsupportedRelOperatorException: This
> query cannot be planned possibly due to either a cartesian join or an
> inequality join
> {code}
> The common pattern between these queries is that function MIN is running over
> no rows, in both queries there is no correlation to the outer table.
> {code}
> -- Non correlated
> -- Greater than
> -- MIN returns NULL
> select * from j2 where c_integer > (select min(c_bigint) from j7 where
> c_boolean is null);
> -- Non correlated
> -- Less than
> -- MIN returns NULL
> select * from j2 where c_float < (select min(c_float) from j6 where c_boolean
> is null );
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DRILL-3018) Queries with scalar aggregate and non equality (non correlated) fail to plan
[
https://issues.apache.org/jira/browse/DRILL-3018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14538459#comment-14538459
]
Jinfeng Ni commented on DRILL-3018:
---
[~amansinha100], could you please review the patch?
> Queries with scalar aggregate and non equality (non correlated) fail to plan
> -
>
> Key: DRILL-3018
> URL: https://issues.apache.org/jira/browse/DRILL-3018
> Project: Apache Drill
> Issue Type: Bug
> Components: Query Planning & Optimization
>Affects Versions: 1.0.0
>Reporter: Victoria Markman
>Assignee: Jinfeng Ni
> Fix For: 1.0.0
>
> Attachments:
> 0001-DRILL-3018-Fix-CanNotPlan-for-nestLoop-left-join-cau.patch, tables.tar
>
>
> This is a regression.
> Both queries worked and returned correct result with May 7 build
> (mapr-drill-1.0.0.31658-1.noarch.rpm)
> Running with the latest build, I got these two failures:
> {code}
> select * from j2 where c_integer > (select min(c_bigint) from j7 where
> c_boolean is null)
> Failed with exception
> java.sql.SQLException: SYSTEM ERROR:
> org.apache.drill.exec.work.foreman.UnsupportedRelOperatorException: This
> query cannot be planned possibly due to either a cartesian join or an
> inequality
> select * from j2 where c_float < (select min(c_float) from j6 where c_boolean
> is null )
> Failed with exception
> java.sql.SQLException: SYSTEM ERROR:
> org.apache.drill.exec.work.foreman.UnsupportedRelOperatorException: This
> query cannot be planned possibly due to either a cartesian join or an
> inequality join
> {code}
> The common pattern between these queries is that function MIN is running over
> no rows, in both queries there is no correlation to the outer table.
> {code}
> -- Non correlated
> -- Greater than
> -- MIN returns NULL
> select * from j2 where c_integer > (select min(c_bigint) from j7 where
> c_boolean is null);
> -- Non correlated
> -- Less than
> -- MIN returns NULL
> select * from j2 where c_float < (select min(c_float) from j6 where c_boolean
> is null );
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DRILL-3018) Queries with scalar aggregate and non equality (non correlated) fail to plan
[
https://issues.apache.org/jira/browse/DRILL-3018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14538481#comment-14538481
]
Aman Sinha commented on DRILL-3018:
---
+1. My only comment is this estimation adjustment should ideally be done in
the base class RelMdRowCount.
> Queries with scalar aggregate and non equality (non correlated) fail to plan
> -
>
> Key: DRILL-3018
> URL: https://issues.apache.org/jira/browse/DRILL-3018
> Project: Apache Drill
> Issue Type: Bug
> Components: Query Planning & Optimization
>Affects Versions: 1.0.0
>Reporter: Victoria Markman
>Assignee: Jinfeng Ni
> Fix For: 1.0.0
>
> Attachments:
> 0001-DRILL-3018-Fix-CanNotPlan-for-nestLoop-left-join-cau.patch, tables.tar
>
>
> This is a regression.
> Both queries worked and returned correct result with May 7 build
> (mapr-drill-1.0.0.31658-1.noarch.rpm)
> Running with the latest build, I got these two failures:
> {code}
> select * from j2 where c_integer > (select min(c_bigint) from j7 where
> c_boolean is null)
> Failed with exception
> java.sql.SQLException: SYSTEM ERROR:
> org.apache.drill.exec.work.foreman.UnsupportedRelOperatorException: This
> query cannot be planned possibly due to either a cartesian join or an
> inequality
> select * from j2 where c_float < (select min(c_float) from j6 where c_boolean
> is null )
> Failed with exception
> java.sql.SQLException: SYSTEM ERROR:
> org.apache.drill.exec.work.foreman.UnsupportedRelOperatorException: This
> query cannot be planned possibly due to either a cartesian join or an
> inequality join
> {code}
> The common pattern between these queries is that function MIN is running over
> no rows, in both queries there is no correlation to the outer table.
> {code}
> -- Non correlated
> -- Greater than
> -- MIN returns NULL
> select * from j2 where c_integer > (select min(c_bigint) from j7 where
> c_boolean is null);
> -- Non correlated
> -- Less than
> -- MIN returns NULL
> select * from j2 where c_float < (select min(c_float) from j6 where c_boolean
> is null );
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DRILL-3018) Queries with scalar aggregate and non equality (non correlated) fail to plan
[
https://issues.apache.org/jira/browse/DRILL-3018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14538596#comment-14538596
]
Jinfeng Ni commented on DRILL-3018:
---
Agree. Will try to push the change back to Calcite later on.
> Queries with scalar aggregate and non equality (non correlated) fail to plan
> -
>
> Key: DRILL-3018
> URL: https://issues.apache.org/jira/browse/DRILL-3018
> Project: Apache Drill
> Issue Type: Bug
> Components: Query Planning & Optimization
>Affects Versions: 1.0.0
>Reporter: Victoria Markman
>Assignee: Jinfeng Ni
> Fix For: 1.0.0
>
> Attachments:
> 0001-DRILL-3018-Fix-CanNotPlan-for-nestLoop-left-join-cau.patch, tables.tar
>
>
> This is a regression.
> Both queries worked and returned correct result with May 7 build
> (mapr-drill-1.0.0.31658-1.noarch.rpm)
> Running with the latest build, I got these two failures:
> {code}
> select * from j2 where c_integer > (select min(c_bigint) from j7 where
> c_boolean is null)
> Failed with exception
> java.sql.SQLException: SYSTEM ERROR:
> org.apache.drill.exec.work.foreman.UnsupportedRelOperatorException: This
> query cannot be planned possibly due to either a cartesian join or an
> inequality
> select * from j2 where c_float < (select min(c_float) from j6 where c_boolean
> is null )
> Failed with exception
> java.sql.SQLException: SYSTEM ERROR:
> org.apache.drill.exec.work.foreman.UnsupportedRelOperatorException: This
> query cannot be planned possibly due to either a cartesian join or an
> inequality join
> {code}
> The common pattern between these queries is that function MIN is running over
> no rows, in both queries there is no correlation to the outer table.
> {code}
> -- Non correlated
> -- Greater than
> -- MIN returns NULL
> select * from j2 where c_integer > (select min(c_bigint) from j7 where
> c_boolean is null);
> -- Non correlated
> -- Less than
> -- MIN returns NULL
> select * from j2 where c_float < (select min(c_float) from j6 where c_boolean
> is null );
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DRILL-2778) Killing the drillbit which is the foreman results in hung sqlline
[ https://issues.apache.org/jira/browse/DRILL-2778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14538603#comment-14538603 ] Ramana Inukonda Nagaraj commented on DRILL-2778: sqlline still hangs when the query is cancelled. Although you can get out of the hang by doing a ctrl-c which was not possible earlier. Had to manually kill sqlline process on previous test attempts. > Killing the drillbit which is the foreman results in hung sqlline > - > > Key: DRILL-2778 > URL: https://issues.apache.org/jira/browse/DRILL-2778 > Project: Apache Drill > Issue Type: Bug > Components: Execution - Flow >Reporter: Ramana Inukonda Nagaraj >Assignee: Jacques Nadeau > Fix For: 1.0.0 > > > Killed one of the drillbits which is the foreman for the query- > Profiles page reports that query has cancelled. > sqlline hangs though- Does not look like the cancel went all the way through. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-2476) Handle IterOutcome.STOP in buildSchema()
[
https://issues.apache.org/jira/browse/DRILL-2476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheesh Katkam updated DRILL-2476:
---
Attachment: DRILL-2476.2.patch.txt
> Handle IterOutcome.STOP in buildSchema()
>
>
> Key: DRILL-2476
> URL: https://issues.apache.org/jira/browse/DRILL-2476
> Project: Apache Drill
> Issue Type: Bug
> Components: Execution - Relational Operators
>Affects Versions: 0.7.0
>Reporter: Sudheesh Katkam
>Assignee: Steven Phillips
> Fix For: 1.0.0
>
> Attachments: DRILL-2476.1.patch.txt, DRILL-2476.2.patch.txt
>
>
> There are some {{RecordBatch}} implementations like {{HashAggBatch}} that
> override the {{buildSchema()}} function. The overriding functions do not
> handle {{IterOutcome.STOP}}. This causes the {{FragmentContext}} to receive
> two failures in some cases (linked JIRAs).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DRILL-1942) Improve off-heap memory usage tracking
[ https://issues.apache.org/jira/browse/DRILL-1942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Nadeau updated DRILL-1942: -- Fix Version/s: (was: 1.0.0) 1.1.0 > Improve off-heap memory usage tracking > -- > > Key: DRILL-1942 > URL: https://issues.apache.org/jira/browse/DRILL-1942 > Project: Apache Drill > Issue Type: Improvement > Components: Execution - Relational Operators >Reporter: Chris Westin >Assignee: Chris Westin > Fix For: 1.1.0 > > Attachments: DRILL-1942.1.patch.txt, DRILL-1942.2.patch.txt, > DRILL-1942.3.patch.txt > > > We're using a lot more memory than we think we should. We may be leaking it, > or not releasing it as soon as we could. > This is a call to come up with some improved tracking so that we can get > statistics out about exactly where we're using it, and whether or not we can > release it earlier. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (DRILL-2957) Netty Memory Manager doesn't move empty chunks between lists
[ https://issues.apache.org/jira/browse/DRILL-2957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Nadeau resolved DRILL-2957. --- Resolution: Not A Problem > Netty Memory Manager doesn't move empty chunks between lists > > > Key: DRILL-2957 > URL: https://issues.apache.org/jira/browse/DRILL-2957 > Project: Apache Drill > Issue Type: Bug > Components: Execution - Flow >Reporter: Jacques Nadeau >Assignee: Jacques Nadeau >Priority: Critical > Fix For: 1.0.0 > > > I'm seeing a pattern in the memory allocator and I need you to take a look at > it. Here are the basic concepts: > 1) We use an extension of PooledByteBufAllocator [1] called > PooledByteBufAllocatorL. > 2) We use many Direct Arenas (generally one per core) > 3) Each arena has chunk lists for different occupancies (chunks that are > empty, chunks 25% full, chunks 50% full, etc) [2] > 4) Each of these chunk lists maintains a list of chunks. The chunks move > from list to list as they get more or less full. > 5) When no memory is being used, chunks move back to the empty list. > 6) If there are excessive empty chunks, they are released back to the OS. (I > don't remember the exact trigger here and I'm only seeing this sometimes > right now.) > We're running on Netty 4.0.27. > What I'm seeing is that we don't seem to be moving the chunks back to the > empty list as they are vacated. You can see an example output from my memory > logging [3] that is enabled by [4]. I haven't replicated this at small scale > but at large scale I see it consistently (30 node cluster, large group by > query [5]). > I want to understand this behavior better, determine if it is a bug or not > and determine whether or not this hurts memory for subsequent queries. > One other note, Netty will cache small amounts of memory that is allocated > and released on the same thread for that thread. I don't believe this is a > large amount of memory but be aware of it. It should be possible to control > this using these settings [6]. > [1] > https://github.com/netty/netty/blob/master/buffer/src/main/java/io/netty/buffer/PooledByteBufAllocator.java > [2] > https://github.com/netty/netty/blob/master/buffer/src/main/java/io/netty/buffer/PoolArena.java#L67 > [3] Memory log output at idle after large query (one example arena out of 32 > on perf cluster, see logs on those nodes for more info): > ::snip:: > Chunk(s) at 0~25%: > none > Chunk(s) at 0~50%: > Chunk(62194b16: 0%, 0/16777216) > Chunk(35983868: 1%, 8192/16777216) > Chunk(5bbfb16a: 1%, 163840/16777216) > Chunk(1c6d277e: 1%, 8192/16777216) > Chunk(2897b6bf: 2%, 204800/16777216) > Chunk(287d5c71: 0%, 0/16777216) > Chunk(s) at 25~75%: > Chunk(61bad0ee: 0%, 0/16777216) > Chunk(s) at 50~100%: > Chunk(2d79a032: 0%, 0/16777216) > Chunk(42415f4e: 0%, 0/16777216) > Chunk(33a3bade: 0%, 0/16777216) > Chunk(1ce7ca63: 0%, 0/16777216) > Chunk(531e1888: 0%, 0/16777216) > Chunk(54786a09: 0%, 0/16777216) > Chunk(5cdcb359: 0%, 0/16777216) > Chunk(3e40137b: 0%, 0/16777216) > Chunk(534f0fb3: 0%, 0/16777216) > Chunk(6301ee8a: 0%, 0/16777216) > Chunk(6a90c3aa: 0%, 0/16777216) > Chunk(s) at 75~100%: > none > Chunk(s) at 100%: > none > ::snip:: > [4] Enable the memory logger by enabling trace level debugging for the > "drill.allocator" logger like this: > > > > > > [5] On perf cluster > # sqllineTPCDS > ALTER SESSION SET `exec.errors.verbose` = true; > ALTER SESSION SET `planner.enable_multiphase_agg` = false; > ALTER SESSION SET `store.parquet.block-size` = 134217728; > ALTER SESSION SET `planner.enable_mux_exchange` = false; > ALTER SESSION SET `exec.min_hash_table_size` = 67108864; > ALTER SESSION SET `planner.enable_hashagg` = true; > ALTER SESSION SET `planner.memory.max_query_memory_per_node` = 29205777612; > ALTER SESSION SET `planner.width.max_per_node` = 23; > create table dfs.tmp.agg33 as > select ss_sold_date_sk , ss_sold_time_sk , ss_item_sk , ss_customer_sk , > ss_cdemo_sk, count(*) from `store_sales_dri3` > group by ss_sold_date_sk , ss_sold_time_sk , ss_item_sk , ss_customer_sk , > ss_cdemo_sk; > [6] > https://github.com/netty/netty/blob/master/buffer/src/main/java/io/netty/buffer/PooledByteBufAllocator.java#L98 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-2010) merge join returns wrong number of rows with large dataset
[
https://issues.apache.org/jira/browse/DRILL-2010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacques Nadeau updated DRILL-2010:
--
Fix Version/s: (was: 1.0.0)
1.1.0
> merge join returns wrong number of rows with large dataset
> --
>
> Key: DRILL-2010
> URL: https://issues.apache.org/jira/browse/DRILL-2010
> Project: Apache Drill
> Issue Type: Bug
> Components: Execution - Relational Operators
>Affects Versions: 0.8.0
>Reporter: Chun Chang
>Assignee: Venki Korukanti
>Priority: Critical
> Fix For: 1.1.0
>
> Attachments: DRILL-2010-1.patch, DRILL-2010-1.patch
>
>
> #Mon Jan 12 18:19:31 EST 2015
> git.commit.id.abbrev=5b012bf
> When data set is big enough (like larger than one batch size), merge join
> will not returns the correct number of rows. Hash join returns the correct
> number of rows. Data can be downloaded from:
> https://s3.amazonaws.com/apache-drill/files/complex100k.json.gz
> With this dataset, the following query should return 10,000,000.
> {code}
> 0: jdbc:drill:schema=dfs.drillTestDirComplexJ> alter session set
> `planner.enable_mergejoin` = true;
> +++
> | ok | summary |
> +++
> | true | planner.enable_mergejoin updated. |
> +++
> 1 row selected (0.024 seconds)
> 0: jdbc:drill:schema=dfs.drillTestDirComplexJ> alter session set
> `planner.enable_hashjoin` = false;
> +++
> | ok | summary |
> +++
> | true | planner.enable_hashjoin updated. |
> +++
> 1 row selected (0.024 seconds)
> 0: jdbc:drill:schema=dfs.drillTestDirComplexJ> select count(a.id) from
> `complex100k.json` a inner join `complex100k.json` b on a.gbyi=b.gbyi;
> ++
> | EXPR$0 |
> ++
> | 9046760|
> ++
> 1 row selected (6.205 seconds)
> 0: jdbc:drill:schema=dfs.drillTestDirComplexJ> alter session set
> `planner.enable_mergejoin` = false;
> +++
> | ok | summary |
> +++
> | true | planner.enable_mergejoin updated. |
> +++
> 1 row selected (0.026 seconds)
> 0: jdbc:drill:schema=dfs.drillTestDirComplexJ> alter session set
> `planner.enable_hashjoin` = true;
> +++
> | ok | summary |
> +++
> | true | planner.enable_hashjoin updated. |
> +++
> 1 row selected (0.024 seconds)
> 0: jdbc:drill:schema=dfs.drillTestDirComplexJ> select count(a.id) from
> `complex100k.json` a inner join `complex100k.json` b on a.gbyi=b.gbyi;
> ++
> | EXPR$0 |
> ++
> | 1000 |
> ++
> 1 row selected (4.453 seconds)
> {code}
> With smaller dataset, both merge and hash join returns the same correct
> number.
> physical plan for merge join:
> {code}
> 0: jdbc:drill:schema=dfs.drillTestDirComplexJ> explain plan for select
> count(a.id) from `complex100k.json` a inner join `complex100k.json` b on
> a.gbyi=b.gbyi;
> +++
> |text|json|
> +++
> | 00-00Screen
> 00-01 StreamAgg(group=[{}], EXPR$0=[COUNT($0)])
> 00-02Project(id=[$1])
> 00-03 MergeJoin(condition=[=($0, $2)], joinType=[inner])
> 00-05SelectionVectorRemover
> 00-07 Sort(sort0=[$0], dir0=[ASC])
> 00-09Scan(groupscan=[EasyGroupScan
> [selectionRoot=/drill/testdata/complex_type/json/complex100k.json,
> numFiles=1, columns=[`gbyi`, `id`],
> files=[maprfs:/drill/testdata/complex_type/json/complex100k.json]]])
> 00-04Project(gbyi0=[$0])
> 00-06 SelectionVectorRemover
> 00-08Sort(sort0=[$0], dir0=[ASC])
> 00-10 Scan(groupscan=[EasyGroupScan
> [selectionRoot=/drill/testdata/complex_type/json/complex100k.json,
> numFiles=1, columns=[`gbyi`],
> files=[maprfs:/drill/testdata/complex_type/json/complex100k.json]]])
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (DRILL-2554) Incorrect results for repeated values when using jdbc
[
https://issues.apache.org/jira/browse/DRILL-2554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacques Nadeau resolved DRILL-2554.
---
Resolution: Fixed
resolved by DRILL-2150
> Incorrect results for repeated values when using jdbc
> -
>
> Key: DRILL-2554
> URL: https://issues.apache.org/jira/browse/DRILL-2554
> Project: Apache Drill
> Issue Type: Bug
> Components: Client - JDBC, Execution - Data Types
>Affects Versions: 0.8.0
>Reporter: Khurram Faraaz
>Assignee: Parth Chandra
>Priority: Critical
> Fix For: 1.0.0
>
>
> Data is missing from the output of select * from JSON data file statement.
> Data pertaining to key2 and key3 and key4 is missing from the output of the
> below select statement. I had enabled `store.json.all_text_mode`=true for
> that session.
> {code}
> 0: jdbc:drill:> alter session set `store.json.all_text_mode`=true;
> +++
> | ok | summary |
> +++
> | true | store.json.all_text_mode updated. |
> +++
> 1 row selected (0.022 seconds)
> 0: jdbc:drill:> select * from `testJsnData02.json`;
> ++++++
> |key |key1|key2|key3|key4|
> ++++++
> | 12345 | {} | [] | {} | [] |
> | -123456| {} | [] | {} | null |
> | 0 | {} | [] | {} | null |
> | -9.999 | {} | [] | {} | null |
> | .9876 | {} | [] | {} | null |
> | Hello World! | {} | [] | {} | null |
> | this is a long string, not very long though! | {} | [] | {}
> | null |
> | true | {} | [] | {} | null |
> | false | {} | [] | {} | null |
> | null | {} | [] | {} | null |
> | 2147483647 | {} | [] | {} | null |
> | 1100110010101010100101010101010101 | {} | [] | {} |
> null |
> | 2008-1-23 14:24:23 | {} | [] | {} | null |
> | 2008-2-23 | {} | [] | {} | null |
> | 10:20:30.123 | {} | null | {} | null |
> | -1 | {} | null | {} | null |
> | 3.147 | {} | null | {} | null |
> | null | {"id":"1000.997"} | null | {} | null |
> | null | {} | null | {} | null |
> | null | {} | null | {} | null |
> | null | {} | null | {} | null |
> | abcdefghijklmnopqrstuvwxyz1234567890ABCDEFGHIJKLMNOPQRSTUVWXYZ12345
> aeiou | {} | null | {} | null |
> ++++++
> 22 rows selected (0.069 seconds)
> 0: jdbc:drill:> select * from sys.version;
> +++-+-++
> | commit_id | commit_message | commit_time | build_email | build_time |
> +++-+-++
> | f658a3c513ddf7f2d1b0ad7aa1f3f65049a594fe | DRILL-2209 Insert
> ProjectOperator with MuxExchange | 09.03.2015 @ 01:49:18 EDT | Unknown |
> 09.03.2015 @ 04:52:49 EDT |
> +++-+-++
> 1 row selected (0.041 seconds)
> {code}
> The data that I used in my test was
> {code}
> {"key":12345}
> {"key":-123456}
> {"key":0}
> {"key":-9.999}
> {"key":.9876}
> {"key":"Hello World!"}
> {"key":"this is a long string, not very long though!"}
> {"key":true}
> {"key":false}
> {"key":null}
> {"key":2147483647}
> {"key":1100110010101010100101010101010101}
> {"key":"2008-1-23 14:24:23"}
> {"key":"2008-2-23"}
> {"key":"10:20:30.123"}
> {"key":-1}
> {"key":3.147}
> {"key1":{"id":1000.997}}
> {"key2":[1,2,3,4,-1,0,135.987,9,-.876,2147483647,"test
> string",null,true,false]}
> {"key3":{"id":null}}
> {"key4":[null]}
> {"key":"abcdefghijklmnopqrstuvwxyz1234567890ABCDEFGHIJKLMNOPQRSTUVWXYZ
> 12345 aeiou"}
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DRILL-3018) Queries with scalar aggregate and non equality (non correlated) fail to plan
[
https://issues.apache.org/jira/browse/DRILL-3018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14538632#comment-14538632
]
Jinfeng Ni commented on DRILL-3018:
---
Fixed in commit a7359f36b517e667b7e64a474154fb5b2238e620
> Queries with scalar aggregate and non equality (non correlated) fail to plan
> -
>
> Key: DRILL-3018
> URL: https://issues.apache.org/jira/browse/DRILL-3018
> Project: Apache Drill
> Issue Type: Bug
> Components: Query Planning & Optimization
>Affects Versions: 1.0.0
>Reporter: Victoria Markman
>Assignee: Jinfeng Ni
> Fix For: 1.0.0
>
> Attachments:
> 0001-DRILL-3018-Fix-CanNotPlan-for-nestLoop-left-join-cau.patch, tables.tar
>
>
> This is a regression.
> Both queries worked and returned correct result with May 7 build
> (mapr-drill-1.0.0.31658-1.noarch.rpm)
> Running with the latest build, I got these two failures:
> {code}
> select * from j2 where c_integer > (select min(c_bigint) from j7 where
> c_boolean is null)
> Failed with exception
> java.sql.SQLException: SYSTEM ERROR:
> org.apache.drill.exec.work.foreman.UnsupportedRelOperatorException: This
> query cannot be planned possibly due to either a cartesian join or an
> inequality
> select * from j2 where c_float < (select min(c_float) from j6 where c_boolean
> is null )
> Failed with exception
> java.sql.SQLException: SYSTEM ERROR:
> org.apache.drill.exec.work.foreman.UnsupportedRelOperatorException: This
> query cannot be planned possibly due to either a cartesian join or an
> inequality join
> {code}
> The common pattern between these queries is that function MIN is running over
> no rows, in both queries there is no correlation to the outer table.
> {code}
> -- Non correlated
> -- Greater than
> -- MIN returns NULL
> select * from j2 where c_integer > (select min(c_bigint) from j7 where
> c_boolean is null);
> -- Non correlated
> -- Less than
> -- MIN returns NULL
> select * from j2 where c_float < (select min(c_float) from j6 where c_boolean
> is null );
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (DRILL-3025) Tibco Spotfire Server - JDBC - Configuration Document
[ https://issues.apache.org/jira/browse/DRILL-3025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bob Rumsby reassigned DRILL-3025: - Assignee: Bob Rumsby (was: Bridget Bevens) > Tibco Spotfire Server - JDBC - Configuration Document > - > > Key: DRILL-3025 > URL: https://issues.apache.org/jira/browse/DRILL-3025 > Project: Apache Drill > Issue Type: Improvement > Components: Documentation >Affects Versions: 1.0.0 >Reporter: Andries Engelbrecht >Assignee: Bob Rumsby > Attachments: Tibco Spotfire Server 6.0 Drill Configuration.docx > > > TSS Configuration document - JDBC -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (DRILL-2946) Tableau 9.0 Desktop Enablement Document
[ https://issues.apache.org/jira/browse/DRILL-2946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bob Rumsby reassigned DRILL-2946: - Assignee: Bob Rumsby (was: Bridget Bevens) > Tableau 9.0 Desktop Enablement Document > --- > > Key: DRILL-2946 > URL: https://issues.apache.org/jira/browse/DRILL-2946 > Project: Apache Drill > Issue Type: Improvement > Components: Documentation >Affects Versions: 0.9.0 >Reporter: Andries Engelbrecht >Assignee: Bob Rumsby > Attachments: Tableau 9 Desktop Drill Configuration.docx > > > Documentation for Tableau 9.0 Desktop enablement. > Includes authentication with Drill 0.9 and later. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (DRILL-2982) Tableau 9.0 Server Enablement Documentation
[ https://issues.apache.org/jira/browse/DRILL-2982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bob Rumsby reassigned DRILL-2982: - Assignee: Bob Rumsby (was: Bridget Bevens) > Tableau 9.0 Server Enablement Documentation > --- > > Key: DRILL-2982 > URL: https://issues.apache.org/jira/browse/DRILL-2982 > Project: Apache Drill > Issue Type: Improvement > Components: Documentation >Affects Versions: 0.9.0, 1.0.0 >Reporter: Andries Engelbrecht >Assignee: Bob Rumsby > Attachments: Tableau 9 Server Drill Configuration.docx > > > Tableau 9.0 Server Enablement document -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DRILL-2274) Unable to allocate sv2 buffer after repeated attempts : JOIN, Order by used in query
[
https://issues.apache.org/jira/browse/DRILL-2274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14538651#comment-14538651
]
Rahul Challapalli commented on DRILL-2274:
--
I am still hitting the issue. Below is the plan for the query
{code}
00-00Screen
00-01 SingleMergeExchange(sort0=[0 ASC])
01-01SelectionVectorRemover
01-02 Sort(sort0=[$0], dir0=[ASC])
01-03Project(uid=[$0])
01-04 HashJoin(condition=[=($0, $1)], joinType=[inner])
01-05Project(uid0=[$0])
01-07 Project(uid=[$0])
01-09HashToRandomExchange(dist0=[[$0]])
03-01 UnorderedMuxExchange
05-01Project(uid=[$0],
E_X_P_R_H_A_S_H_F_I_E_L_D=[castInt(hash64AsDouble($0))])
05-02 Scan(groupscan=[EasyGroupScan
[selectionRoot=/drill/testdata/flatten_operators/10rows/data.json,
numFiles=1, columns=[`uid`],
files=[maprfs:/drill/testdata/flatten_operators/10rows/data.json]]])
01-06Project(uid=[$0])
01-08 HashToRandomExchange(dist0=[[$0]])
02-01UnorderedMuxExchange
04-01 Project(uid=[$0],
E_X_P_R_H_A_S_H_F_I_E_L_D=[castInt(hash64AsDouble($0))])
04-02Scan(groupscan=[EasyGroupScan
[selectionRoot=/drill/testdata/flatten_operators/10rows/data.json,
numFiles=1, columns=[`uid`],
files=[maprfs:/drill/testdata/flatten_operators/10rows/data.json]]])
{code}
> Unable to allocate sv2 buffer after repeated attempts : JOIN, Order by used
> in query
>
>
> Key: DRILL-2274
> URL: https://issues.apache.org/jira/browse/DRILL-2274
> Project: Apache Drill
> Issue Type: Bug
> Components: Execution - Relational Operators
>Reporter: Rahul Challapalli
>Assignee: Deneche A. Hakim
> Fix For: 1.0.0
>
> Attachments: data.json
>
>
> git.commit.id.abbrev=6676f2d
> The below query fails :
> {code}
> select sub1.uid from `data.json` sub1 inner join `data.json` sub2 on sub1.uid
> = sub2.uid order by sub1.uid;
> {code}
> Error from the logs :
> {code}
> 2015-02-20 00:24:08,431 [2b1981b0-149e-981b-f83f-512c587321d7:frag:1:2] ERROR
> o.a.d.e.w.f.AbstractStatusReporter - Error
> 66dba4ff-644c-4400-ab84-203256dc2600: Failure while running fragment.
> java.lang.RuntimeException:
> org.apache.drill.exec.memory.OutOfMemoryException: Unable to allocate sv2
> buffer after repeated attempts
> at
> org.apache.drill.exec.physical.impl.xsort.ExternalSortBatch.innerNext(ExternalSortBatch.java:307)
> ~[drill-java-exec-0.8.0-SNAPSHOT-rebuffed.jar:0.8.0-SNAPSHOT]
> at
> org.apache.drill.exec.record.AbstractRecordBatch.next(AbstractRecordBatch.java:142)
> ~[drill-java-exec-0.8.0-SNAPSHOT-rebuffed.jar:0.8.0-SNAPSHOT]
> at
> org.apache.drill.exec.physical.impl.validate.IteratorValidatorBatchIterator.next(IteratorValidatorBatchIterator.java:118)
> ~[drill-java-exec-0.8.0-SNAPSHOT-rebuffed.jar:0.8.0-SNAPSHOT]
> at
> org.apache.drill.exec.record.AbstractRecordBatch.next(AbstractRecordBatch.java:99)
> ~[drill-java-exec-0.8.0-SNAPSHOT-rebuffed.jar:0.8.0-SNAPSHOT]
> at
> org.apache.drill.exec.record.AbstractRecordBatch.next(AbstractRecordBatch.java:89)
> ~[drill-java-exec-0.8.0-SNAPSHOT-rebuffed.jar:0.8.0-SNAPSHOT]
> at
> org.apache.drill.exec.record.AbstractSingleRecordBatch.innerNext(AbstractSingleRecordBatch.java:51)
> ~[drill-java-exec-0.8.0-SNAPSHOT-rebuffed.jar:0.8.0-SNAPSHOT]
> at
> org.apache.drill.exec.physical.impl.svremover.RemovingRecordBatch.innerNext(RemovingRecordBatch.java:96)
> ~[drill-java-exec-0.8.0-SNAPSHOT-rebuffed.jar:0.8.0-SNAPSHOT]
> at
> org.apache.drill.exec.record.AbstractRecordBatch.next(AbstractRecordBatch.java:142)
> ~[drill-java-exec-0.8.0-SNAPSHOT-rebuffed.jar:0.8.0-SNAPSHOT]
> at
> org.apache.drill.exec.physical.impl.validate.IteratorValidatorBatchIterator.next(IteratorValidatorBatchIterator.java:118)
> ~[drill-java-exec-0.8.0-SNAPSHOT-rebuffed.jar:0.8.0-SNAPSHOT]
> at
> org.apache.drill.exec.physical.impl.BaseRootExec.next(BaseRootExec.java:67)
> ~[drill-java-exec-0.8.0-SNAPSHOT-rebuffed.jar:0.8.0-SNAPSHOT]
> at
> org.apache.drill.exec.physical.impl.SingleSenderCreator$SingleSenderRootExec.innerNext(SingleSenderCreator.java:97)
> ~[drill-java-exec-0.8.0-SNAPSHOT-rebuffed.jar:0.8.0-SNAPSHOT]
> at
> org.apache.drill.exec.physical.impl.BaseRootExec.next(BaseRootExec.java:57)
> ~[drill-java-exec-0.8.0-SNAPSHOT-rebuffed.jar:0.8.0-SNAPSHOT]
> at
> org.apache.drill.exec.work.fragment.FragmentExecutor.run(FragmentExecutor.java:116)
> ~[drill-java-exec-0.8.0-SNAPSHOT-rebuffed.jar:0.8.0-SNAPSHOT]
> at
> org.apache.dr
[jira] [Created] (DRILL-3026) Revisit BasicServer
Daniel Barclay (Drill) created DRILL-3026: - Summary: Revisit BasicServer Key: DRILL-3026 URL: https://issues.apache.org/jira/browse/DRILL-3026 Project: Apache Drill Issue Type: Bug Reporter: Daniel Barclay (Drill) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-3026) Revisit BasicServer's check for BindException (IOException also used)
[ https://issues.apache.org/jira/browse/DRILL-3026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Barclay (Drill) updated DRILL-3026: -- Summary: Revisit BasicServer's check for BindException (IOException also used) (was: Revisit BasicServer) > Revisit BasicServer's check for BindException (IOException also used) > - > > Key: DRILL-3026 > URL: https://issues.apache.org/jira/browse/DRILL-3026 > Project: Apache Drill > Issue Type: Bug >Reporter: Daniel Barclay (Drill) > Fix For: Future > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-3026) Revisit BasicServer's check for BindException (IOException also used)
[ https://issues.apache.org/jira/browse/DRILL-3026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Barclay (Drill) updated DRILL-3026: -- Fix Version/s: Future > Revisit BasicServer's check for BindException (IOException also used) > - > > Key: DRILL-3026 > URL: https://issues.apache.org/jira/browse/DRILL-3026 > Project: Apache Drill > Issue Type: Bug >Reporter: Daniel Barclay (Drill) > Fix For: Future > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-3026) Revisit BasicServer's check for BindException (IOException also used)
[ https://issues.apache.org/jira/browse/DRILL-3026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Barclay (Drill) updated DRILL-3026: -- Description: Revisit BasicServer's detection of port-binding problems. It checks for BindException, but BindException is not the only exception used to report port-binding failures. (For example, sometimes IOException is used: "java.io.IOException: bind() failed: Address already in use".) > Revisit BasicServer's check for BindException (IOException also used) > - > > Key: DRILL-3026 > URL: https://issues.apache.org/jira/browse/DRILL-3026 > Project: Apache Drill > Issue Type: Bug >Reporter: Daniel Barclay (Drill) > Fix For: Future > > > Revisit BasicServer's detection of port-binding problems. > It checks for BindException, but BindException is not the only exception used > to report port-binding failures. (For example, sometimes IOException is > used: "java.io.IOException: bind() failed: Address already in use".) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DRILL-2957) Netty Memory Manager doesn't move empty chunks between lists
[ https://issues.apache.org/jira/browse/DRILL-2957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14538676#comment-14538676 ] Steven Phillips commented on DRILL-2957: What's the explanation for why this is not a problem? > Netty Memory Manager doesn't move empty chunks between lists > > > Key: DRILL-2957 > URL: https://issues.apache.org/jira/browse/DRILL-2957 > Project: Apache Drill > Issue Type: Bug > Components: Execution - Flow >Reporter: Jacques Nadeau >Assignee: Jacques Nadeau >Priority: Critical > Fix For: 1.0.0 > > > I'm seeing a pattern in the memory allocator and I need you to take a look at > it. Here are the basic concepts: > 1) We use an extension of PooledByteBufAllocator [1] called > PooledByteBufAllocatorL. > 2) We use many Direct Arenas (generally one per core) > 3) Each arena has chunk lists for different occupancies (chunks that are > empty, chunks 25% full, chunks 50% full, etc) [2] > 4) Each of these chunk lists maintains a list of chunks. The chunks move > from list to list as they get more or less full. > 5) When no memory is being used, chunks move back to the empty list. > 6) If there are excessive empty chunks, they are released back to the OS. (I > don't remember the exact trigger here and I'm only seeing this sometimes > right now.) > We're running on Netty 4.0.27. > What I'm seeing is that we don't seem to be moving the chunks back to the > empty list as they are vacated. You can see an example output from my memory > logging [3] that is enabled by [4]. I haven't replicated this at small scale > but at large scale I see it consistently (30 node cluster, large group by > query [5]). > I want to understand this behavior better, determine if it is a bug or not > and determine whether or not this hurts memory for subsequent queries. > One other note, Netty will cache small amounts of memory that is allocated > and released on the same thread for that thread. I don't believe this is a > large amount of memory but be aware of it. It should be possible to control > this using these settings [6]. > [1] > https://github.com/netty/netty/blob/master/buffer/src/main/java/io/netty/buffer/PooledByteBufAllocator.java > [2] > https://github.com/netty/netty/blob/master/buffer/src/main/java/io/netty/buffer/PoolArena.java#L67 > [3] Memory log output at idle after large query (one example arena out of 32 > on perf cluster, see logs on those nodes for more info): > ::snip:: > Chunk(s) at 0~25%: > none > Chunk(s) at 0~50%: > Chunk(62194b16: 0%, 0/16777216) > Chunk(35983868: 1%, 8192/16777216) > Chunk(5bbfb16a: 1%, 163840/16777216) > Chunk(1c6d277e: 1%, 8192/16777216) > Chunk(2897b6bf: 2%, 204800/16777216) > Chunk(287d5c71: 0%, 0/16777216) > Chunk(s) at 25~75%: > Chunk(61bad0ee: 0%, 0/16777216) > Chunk(s) at 50~100%: > Chunk(2d79a032: 0%, 0/16777216) > Chunk(42415f4e: 0%, 0/16777216) > Chunk(33a3bade: 0%, 0/16777216) > Chunk(1ce7ca63: 0%, 0/16777216) > Chunk(531e1888: 0%, 0/16777216) > Chunk(54786a09: 0%, 0/16777216) > Chunk(5cdcb359: 0%, 0/16777216) > Chunk(3e40137b: 0%, 0/16777216) > Chunk(534f0fb3: 0%, 0/16777216) > Chunk(6301ee8a: 0%, 0/16777216) > Chunk(6a90c3aa: 0%, 0/16777216) > Chunk(s) at 75~100%: > none > Chunk(s) at 100%: > none > ::snip:: > [4] Enable the memory logger by enabling trace level debugging for the > "drill.allocator" logger like this: > > > > > > [5] On perf cluster > # sqllineTPCDS > ALTER SESSION SET `exec.errors.verbose` = true; > ALTER SESSION SET `planner.enable_multiphase_agg` = false; > ALTER SESSION SET `store.parquet.block-size` = 134217728; > ALTER SESSION SET `planner.enable_mux_exchange` = false; > ALTER SESSION SET `exec.min_hash_table_size` = 67108864; > ALTER SESSION SET `planner.enable_hashagg` = true; > ALTER SESSION SET `planner.memory.max_query_memory_per_node` = 29205777612; > ALTER SESSION SET `planner.width.max_per_node` = 23; > create table dfs.tmp.agg33 as > select ss_sold_date_sk , ss_sold_time_sk , ss_item_sk , ss_customer_sk , > ss_cdemo_sk, count(*) from `store_sales_dri3` > group by ss_sold_date_sk , ss_sold_time_sk , ss_item_sk , ss_customer_sk , > ss_cdemo_sk; > [6] > https://github.com/netty/netty/blob/master/buffer/src/main/java/io/netty/buffer/PooledByteBufAllocator.java#L98 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (DRILL-3027) Add convenience methods for creating baseline values to test builder
Hanifi Gunes created DRILL-3027: --- Summary: Add convenience methods for creating baseline values to test builder Key: DRILL-3027 URL: https://issues.apache.org/jira/browse/DRILL-3027 Project: Apache Drill Issue Type: Improvement Components: Tools, Build & Test Affects Versions: 0.9.0 Reporter: Hanifi Gunes Assignee: Hanifi Gunes When building a test case, we often need to create list instances to set baseline values in Java space(as opposed to using baseline queries). This issue proposes adding a static utility method TestBuilder#listOf(values) to expedite process of creating lists. The same applies for maps such like TestBuilder#mapOf(keyValueSequence) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-3027) Add convenience methods to test builder for creating nested baseline values
[ https://issues.apache.org/jira/browse/DRILL-3027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hanifi Gunes updated DRILL-3027: Summary: Add convenience methods to test builder for creating nested baseline values (was: Add convenience methods to test builder for creating baseline values) > Add convenience methods to test builder for creating nested baseline values > --- > > Key: DRILL-3027 > URL: https://issues.apache.org/jira/browse/DRILL-3027 > Project: Apache Drill > Issue Type: Improvement > Components: Tools, Build & Test >Affects Versions: 0.9.0 >Reporter: Hanifi Gunes >Assignee: Hanifi Gunes > > When building a test case, we often need to create list instances to set > baseline values in Java space(as opposed to using baseline queries). This > issue proposes adding a static utility method TestBuilder#listOf(values) to > expedite process of creating lists. The same applies for maps such like > TestBuilder#mapOf(keyValueSequence) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-3027) Add convenience methods to test builder for creating baseline values
[ https://issues.apache.org/jira/browse/DRILL-3027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hanifi Gunes updated DRILL-3027: Summary: Add convenience methods to test builder for creating baseline values (was: Add convenience methods for creating baseline values to test builder) > Add convenience methods to test builder for creating baseline values > > > Key: DRILL-3027 > URL: https://issues.apache.org/jira/browse/DRILL-3027 > Project: Apache Drill > Issue Type: Improvement > Components: Tools, Build & Test >Affects Versions: 0.9.0 >Reporter: Hanifi Gunes >Assignee: Hanifi Gunes > > When building a test case, we often need to create list instances to set > baseline values in Java space(as opposed to using baseline queries). This > issue proposes adding a static utility method TestBuilder#listOf(values) to > expedite process of creating lists. The same applies for maps such like > TestBuilder#mapOf(keyValueSequence) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (DRILL-2946) Tableau 9.0 Desktop Enablement Document
[ https://issues.apache.org/jira/browse/DRILL-2946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bob Rumsby resolved DRILL-2946. --- Resolution: Fixed Target Version/s: 1.0.0 The new page is currently live on Tomer's staging site. > Tableau 9.0 Desktop Enablement Document > --- > > Key: DRILL-2946 > URL: https://issues.apache.org/jira/browse/DRILL-2946 > Project: Apache Drill > Issue Type: Improvement > Components: Documentation >Affects Versions: 0.9.0 >Reporter: Andries Engelbrecht >Assignee: Bob Rumsby > Attachments: Tableau 9 Desktop Drill Configuration.docx > > > Documentation for Tableau 9.0 Desktop enablement. > Includes authentication with Drill 0.9 and later. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-2953) Group By + Order By query results are not ordered.
[
https://issues.apache.org/jira/browse/DRILL-2953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinfeng Ni updated DRILL-2953:
--
Attachment: 0001-DRILL-2953-Ensure-sort-would-be-enforced-when-a-cast.patch
> Group By + Order By query results are not ordered.
> --
>
> Key: DRILL-2953
> URL: https://issues.apache.org/jira/browse/DRILL-2953
> Project: Apache Drill
> Issue Type: Bug
> Components: Query Planning & Optimization
>Affects Versions: 0.9.0
> Environment: 10833d2cae9f5312cf0e31f8c9f3f8a9dcdc0c45 | Commit 0.9.0
> release version. | 03.05.2015 @ 14:56:56 EDT
>Reporter: Khurram Faraaz
>Assignee: Jinfeng Ni
>Priority: Critical
> Fix For: 1.0.0
>
> Attachments:
> 0001-DRILL-2953-Ensure-sort-would-be-enforced-when-a-cast.patch
>
>
> Group by + order by query does not return results in correct order. Sort is
> performed before the aggregation is done, which should not be the case.
> Test was performed on 4 node cluster on CentOS.
> {code}
> 0: jdbc:drill:> select cast(columns[0] as int) c1 from `testWindow.csv` t2
> where t2.columns[0] is not null group by columns[0] order by columns[0];
> ++
> | c1 |
> ++
> | 10 |
> | 100|
> | 113|
> | 119|
> | 2 |
> | 50 |
> | 55 |
> | 57 |
> | 61 |
> | 67 |
> | 89 |
> ++
> 11 rows selected (0.218 seconds)
> {code}
> Explain plan for that query that returns wrong results.
> {code}
> 0: jdbc:drill:> explain plan for select cast(columns[0] as int) c1 from
> `testWindow.csv` t2 where t2.columns[0] is not null group by columns[0] order
> by columns[0];
> +++
> |text|json|
> +++
> | 00-00Screen
> 00-01 Project(c1=[$0])
> 00-02Project(c1=[CAST($0):INTEGER], EXPR$1=[$0])
> 00-03 StreamAgg(group=[{0}])
> 00-04Sort(sort0=[$0], dir0=[ASC])
> 00-05 Filter(condition=[IS NOT NULL($0)])
> 00-06Project(ITEM=[ITEM($0, 0)])
> 00-07 Scan(groupscan=[EasyGroupScan
> [selectionRoot=/tmp/testWindow.csv, numFiles=1, columns=[`columns`[0]],
> files=[maprfs:/tmp/testWindow.csv]]])
> {code}
> Incorrect results , not in order.
> {code}
> 0: jdbc:drill:> select cast(columns[0] as int) from `testWindow.csv` t2 where
> t2.columns[0] is not null group by columns[0] order by columns[0];
> ++
> | EXPR$0 |
> ++
> | 10 |
> | 100|
> | 113|
> | 119|
> | 2 |
> | 50 |
> | 55 |
> | 57 |
> | 61 |
> | 67 |
> | 89 |
> ++
> 11 rows selected (0.214 seconds)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DRILL-2953) Group By + Order By query results are not ordered.
[
https://issues.apache.org/jira/browse/DRILL-2953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14538797#comment-14538797
]
Jinfeng Ni commented on DRILL-2953:
---
[~amansinha100], could you please review the patch for this issue? Thanks!
> Group By + Order By query results are not ordered.
> --
>
> Key: DRILL-2953
> URL: https://issues.apache.org/jira/browse/DRILL-2953
> Project: Apache Drill
> Issue Type: Bug
> Components: Query Planning & Optimization
>Affects Versions: 0.9.0
> Environment: 10833d2cae9f5312cf0e31f8c9f3f8a9dcdc0c45 | Commit 0.9.0
> release version. | 03.05.2015 @ 14:56:56 EDT
>Reporter: Khurram Faraaz
>Assignee: Jinfeng Ni
>Priority: Critical
> Fix For: 1.0.0
>
> Attachments:
> 0001-DRILL-2953-Ensure-sort-would-be-enforced-when-a-cast.patch
>
>
> Group by + order by query does not return results in correct order. Sort is
> performed before the aggregation is done, which should not be the case.
> Test was performed on 4 node cluster on CentOS.
> {code}
> 0: jdbc:drill:> select cast(columns[0] as int) c1 from `testWindow.csv` t2
> where t2.columns[0] is not null group by columns[0] order by columns[0];
> ++
> | c1 |
> ++
> | 10 |
> | 100|
> | 113|
> | 119|
> | 2 |
> | 50 |
> | 55 |
> | 57 |
> | 61 |
> | 67 |
> | 89 |
> ++
> 11 rows selected (0.218 seconds)
> {code}
> Explain plan for that query that returns wrong results.
> {code}
> 0: jdbc:drill:> explain plan for select cast(columns[0] as int) c1 from
> `testWindow.csv` t2 where t2.columns[0] is not null group by columns[0] order
> by columns[0];
> +++
> |text|json|
> +++
> | 00-00Screen
> 00-01 Project(c1=[$0])
> 00-02Project(c1=[CAST($0):INTEGER], EXPR$1=[$0])
> 00-03 StreamAgg(group=[{0}])
> 00-04Sort(sort0=[$0], dir0=[ASC])
> 00-05 Filter(condition=[IS NOT NULL($0)])
> 00-06Project(ITEM=[ITEM($0, 0)])
> 00-07 Scan(groupscan=[EasyGroupScan
> [selectionRoot=/tmp/testWindow.csv, numFiles=1, columns=[`columns`[0]],
> files=[maprfs:/tmp/testWindow.csv]]])
> {code}
> Incorrect results , not in order.
> {code}
> 0: jdbc:drill:> select cast(columns[0] as int) from `testWindow.csv` t2 where
> t2.columns[0] is not null group by columns[0] order by columns[0];
> ++
> | EXPR$0 |
> ++
> | 10 |
> | 100|
> | 113|
> | 119|
> | 2 |
> | 50 |
> | 55 |
> | 57 |
> | 61 |
> | 67 |
> | 89 |
> ++
> 11 rows selected (0.214 seconds)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (DRILL-3028) Exception in correlated subquery with exists when columns in subquery are not qualified
Victoria Markman created DRILL-3028:
---
Summary: Exception in correlated subquery with exists when columns
in subquery are not qualified
Key: DRILL-3028
URL: https://issues.apache.org/jira/browse/DRILL-3028
Project: Apache Drill
Issue Type: Bug
Components: Query Planning & Optimization
Affects Versions: 1.0.0
Reporter: Victoria Markman
Assignee: Jinfeng Ni
{code}
0: jdbc:drill:schema=dfs> select a1 from t1 where exists ( select * from t2
where b1 = b2 and a1 > a2) order by a1;
Error: SYSTEM ERROR: java.lang.NumberFormatException: zzz
Fragment 0:0
[Error Id: 2f13436c-048c-4a19-b99b-9d60a8d6bcf4 on atsqa4-133.qa.lab:31010]
(state=,code=0)
{code}
If you qualify columns, query works and returns correct result:
{code}
0: jdbc:drill:schema=dfs> select a1 from t1 where exists ( select * from t2
where t1.b1 = t2.b2 and t1.a1 > t2.a2) order by a1;
++
| a1 |
++
++
No rows selected (1.338 seconds)
{code}
>From drillbit.log
{code}
2015-05-11 22:44:57,895 [2aaecf16-2d9d-1548-1429-543fa1c79243:frag:0:0] INFO
o.a.drill.exec.work.foreman.Foreman - State change requested. RUNNING -->
FAILED
org.apache.drill.common.exceptions.UserRemoteException: SYSTEM ERROR:
java.lang.NumberFormatException: zzz
Fragment 0:0
[Error Id: 3fbdfc29-3fef-4968-b163-dbdefd45cdc6 on atsqa4-133.qa.lab:31010]
at
org.apache.drill.exec.work.foreman.QueryManager$1.statusUpdate(QueryManager.java:460)
[drill-java-exec-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
at
org.apache.drill.exec.work.foreman.QueryManager$RootStatusReporter.statusChange(QueryManager.java:440)
[drill-java-exec-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
at
org.apache.drill.exec.work.fragment.AbstractStatusReporter.fail(AbstractStatusReporter.java:90)
[drill-java-exec-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
at
org.apache.drill.exec.work.fragment.AbstractStatusReporter.fail(AbstractStatusReporter.java:86)
[drill-java-exec-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
at
org.apache.drill.exec.work.fragment.FragmentExecutor.sendFinalState(FragmentExecutor.java:290)
[drill-java-exec-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
at
org.apache.drill.exec.work.fragment.FragmentExecutor.run(FragmentExecutor.java:254)
[drill-java-exec-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
at
org.apache.drill.common.SelfCleaningRunnable.run(SelfCleaningRunnable.java:38)
[drill-common-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
[na:1.7.0_71]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
[na:1.7.0_71]
at java.lang.Thread.run(Thread.java:745) [na:1.7.0_71]
2015-05-11 22:44:57,899 [2aaecf16-2d9d-1548-1429-543fa1c79243:frag:0:0] INFO
o.a.d.e.w.fragment.FragmentExecutor - 2aaecf16-2d9d-1548-1429-543fa1c79243:0:0:
State change requested from FAILED --> CANCELLATION_REQUESTED for
2015-05-11 22:44:57,899 [2aaecf16-2d9d-1548-1429-543fa1c79243:frag:0:0] WARN
o.a.d.e.w.fragment.FragmentExecutor - Ignoring unexpected state transition
FAILED => CANCELLATION_REQUESTED.
2015-05-11 22:44:57,900 [2aaecf16-2d9d-1548-1429-543fa1c79243:frag:0:0] INFO
o.a.drill.exec.work.foreman.Foreman - foreman cleaning up.
2015-05-11 22:44:57,910 [2aaecf16-2d9d-1548-1429-543fa1c79243:frag:0:0] ERROR
o.a.d.exec.work.foreman.QueryManager - Failure while storing Query Profile
java.lang.RuntimeException: java.io.IOException: java.lang.InterruptedException
at
org.apache.drill.exec.store.sys.local.FilePStore.put(FilePStore.java:148)
~[drill-java-exec-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
at
org.apache.drill.exec.work.foreman.QueryManager.writeFinalProfile(QueryManager.java:286)
~[drill-java-exec-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
at
org.apache.drill.exec.work.foreman.Foreman$ForemanResult.close(Foreman.java:731)
[drill-java-exec-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
at
org.apache.drill.exec.work.foreman.Foreman$StateSwitch.processEvent(Foreman.java:826)
[drill-java-exec-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
at
org.apache.drill.exec.work.foreman.Foreman$StateSwitch.processEvent(Foreman.java:768)
[drill-java-exec-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
at
org.apache.drill.common.EventProcessor.sendEvent(EventProcessor.java:73)
[drill-common-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
at
org.apache.drill.exec.work.foreman.Foreman$StateSwitch.moveToState(Foreman.java:770)
[drill-java-exec-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
at
org.apache.drill.exec.work.foreman.Foreman.moveToState(Foreman.java:871)
[drill-java-exec-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
at
org.apache.drill.exec.work.foreman.Fore
[jira] [Updated] (DRILL-3028) Exception in correlated subquery with exists when columns in subquery are not qualified
[
https://issues.apache.org/jira/browse/DRILL-3028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Victoria Markman updated DRILL-3028:
Attachment: t1.parquet
> Exception in correlated subquery with exists when columns in subquery are not
> qualified
> ---
>
> Key: DRILL-3028
> URL: https://issues.apache.org/jira/browse/DRILL-3028
> Project: Apache Drill
> Issue Type: Bug
> Components: Query Planning & Optimization
>Affects Versions: 1.0.0
>Reporter: Victoria Markman
>Assignee: Jinfeng Ni
> Attachments: t1.parquet, t2.parquet
>
>
> {code}
> 0: jdbc:drill:schema=dfs> select a1 from t1 where exists ( select * from t2
> where b1 = b2 and a1 > a2) order by a1;
> Error: SYSTEM ERROR: java.lang.NumberFormatException: zzz
> Fragment 0:0
> [Error Id: 2f13436c-048c-4a19-b99b-9d60a8d6bcf4 on atsqa4-133.qa.lab:31010]
> (state=,code=0)
> {code}
> If you qualify columns, query works and returns correct result:
> {code}
> 0: jdbc:drill:schema=dfs> select a1 from t1 where exists ( select * from t2
> where t1.b1 = t2.b2 and t1.a1 > t2.a2) order by a1;
> ++
> | a1 |
> ++
> ++
> No rows selected (1.338 seconds)
> {code}
> From drillbit.log
> {code}
> 2015-05-11 22:44:57,895 [2aaecf16-2d9d-1548-1429-543fa1c79243:frag:0:0] INFO
> o.a.drill.exec.work.foreman.Foreman - State change requested. RUNNING -->
> FAILED
> org.apache.drill.common.exceptions.UserRemoteException: SYSTEM ERROR:
> java.lang.NumberFormatException: zzz
> Fragment 0:0
> [Error Id: 3fbdfc29-3fef-4968-b163-dbdefd45cdc6 on atsqa4-133.qa.lab:31010]
> at
> org.apache.drill.exec.work.foreman.QueryManager$1.statusUpdate(QueryManager.java:460)
> [drill-java-exec-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
> at
> org.apache.drill.exec.work.foreman.QueryManager$RootStatusReporter.statusChange(QueryManager.java:440)
> [drill-java-exec-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
> at
> org.apache.drill.exec.work.fragment.AbstractStatusReporter.fail(AbstractStatusReporter.java:90)
> [drill-java-exec-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
> at
> org.apache.drill.exec.work.fragment.AbstractStatusReporter.fail(AbstractStatusReporter.java:86)
> [drill-java-exec-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
> at
> org.apache.drill.exec.work.fragment.FragmentExecutor.sendFinalState(FragmentExecutor.java:290)
> [drill-java-exec-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
> at
> org.apache.drill.exec.work.fragment.FragmentExecutor.run(FragmentExecutor.java:254)
> [drill-java-exec-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
> at
> org.apache.drill.common.SelfCleaningRunnable.run(SelfCleaningRunnable.java:38)
> [drill-common-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> [na:1.7.0_71]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> [na:1.7.0_71]
> at java.lang.Thread.run(Thread.java:745) [na:1.7.0_71]
> 2015-05-11 22:44:57,899 [2aaecf16-2d9d-1548-1429-543fa1c79243:frag:0:0] INFO
> o.a.d.e.w.fragment.FragmentExecutor -
> 2aaecf16-2d9d-1548-1429-543fa1c79243:0:0: State change requested from FAILED
> --> CANCELLATION_REQUESTED for
> 2015-05-11 22:44:57,899 [2aaecf16-2d9d-1548-1429-543fa1c79243:frag:0:0] WARN
> o.a.d.e.w.fragment.FragmentExecutor - Ignoring unexpected state transition
> FAILED => CANCELLATION_REQUESTED.
> 2015-05-11 22:44:57,900 [2aaecf16-2d9d-1548-1429-543fa1c79243:frag:0:0] INFO
> o.a.drill.exec.work.foreman.Foreman - foreman cleaning up.
> 2015-05-11 22:44:57,910 [2aaecf16-2d9d-1548-1429-543fa1c79243:frag:0:0] ERROR
> o.a.d.exec.work.foreman.QueryManager - Failure while storing Query Profile
> java.lang.RuntimeException: java.io.IOException:
> java.lang.InterruptedException
> at
> org.apache.drill.exec.store.sys.local.FilePStore.put(FilePStore.java:148)
> ~[drill-java-exec-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
> at
> org.apache.drill.exec.work.foreman.QueryManager.writeFinalProfile(QueryManager.java:286)
> ~[drill-java-exec-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
> at
> org.apache.drill.exec.work.foreman.Foreman$ForemanResult.close(Foreman.java:731)
> [drill-java-exec-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
> at
> org.apache.drill.exec.work.foreman.Foreman$StateSwitch.processEvent(Foreman.java:826)
> [drill-java-exec-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
> at
> org.apache.drill.exec.work.foreman.Foreman$StateSwitch.processEvent(Foreman.java:768)
> [drill-java-exec-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
> at
> org.apache.drill.common.EventProcessor.s
[jira] [Updated] (DRILL-3028) Exception in correlated subquery with exists when columns in subquery are not qualified
[
https://issues.apache.org/jira/browse/DRILL-3028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Victoria Markman updated DRILL-3028:
Attachment: t2.parquet
> Exception in correlated subquery with exists when columns in subquery are not
> qualified
> ---
>
> Key: DRILL-3028
> URL: https://issues.apache.org/jira/browse/DRILL-3028
> Project: Apache Drill
> Issue Type: Bug
> Components: Query Planning & Optimization
>Affects Versions: 1.0.0
>Reporter: Victoria Markman
>Assignee: Jinfeng Ni
> Attachments: t1.parquet, t2.parquet
>
>
> {code}
> 0: jdbc:drill:schema=dfs> select a1 from t1 where exists ( select * from t2
> where b1 = b2 and a1 > a2) order by a1;
> Error: SYSTEM ERROR: java.lang.NumberFormatException: zzz
> Fragment 0:0
> [Error Id: 2f13436c-048c-4a19-b99b-9d60a8d6bcf4 on atsqa4-133.qa.lab:31010]
> (state=,code=0)
> {code}
> If you qualify columns, query works and returns correct result:
> {code}
> 0: jdbc:drill:schema=dfs> select a1 from t1 where exists ( select * from t2
> where t1.b1 = t2.b2 and t1.a1 > t2.a2) order by a1;
> ++
> | a1 |
> ++
> ++
> No rows selected (1.338 seconds)
> {code}
> From drillbit.log
> {code}
> 2015-05-11 22:44:57,895 [2aaecf16-2d9d-1548-1429-543fa1c79243:frag:0:0] INFO
> o.a.drill.exec.work.foreman.Foreman - State change requested. RUNNING -->
> FAILED
> org.apache.drill.common.exceptions.UserRemoteException: SYSTEM ERROR:
> java.lang.NumberFormatException: zzz
> Fragment 0:0
> [Error Id: 3fbdfc29-3fef-4968-b163-dbdefd45cdc6 on atsqa4-133.qa.lab:31010]
> at
> org.apache.drill.exec.work.foreman.QueryManager$1.statusUpdate(QueryManager.java:460)
> [drill-java-exec-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
> at
> org.apache.drill.exec.work.foreman.QueryManager$RootStatusReporter.statusChange(QueryManager.java:440)
> [drill-java-exec-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
> at
> org.apache.drill.exec.work.fragment.AbstractStatusReporter.fail(AbstractStatusReporter.java:90)
> [drill-java-exec-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
> at
> org.apache.drill.exec.work.fragment.AbstractStatusReporter.fail(AbstractStatusReporter.java:86)
> [drill-java-exec-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
> at
> org.apache.drill.exec.work.fragment.FragmentExecutor.sendFinalState(FragmentExecutor.java:290)
> [drill-java-exec-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
> at
> org.apache.drill.exec.work.fragment.FragmentExecutor.run(FragmentExecutor.java:254)
> [drill-java-exec-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
> at
> org.apache.drill.common.SelfCleaningRunnable.run(SelfCleaningRunnable.java:38)
> [drill-common-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> [na:1.7.0_71]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> [na:1.7.0_71]
> at java.lang.Thread.run(Thread.java:745) [na:1.7.0_71]
> 2015-05-11 22:44:57,899 [2aaecf16-2d9d-1548-1429-543fa1c79243:frag:0:0] INFO
> o.a.d.e.w.fragment.FragmentExecutor -
> 2aaecf16-2d9d-1548-1429-543fa1c79243:0:0: State change requested from FAILED
> --> CANCELLATION_REQUESTED for
> 2015-05-11 22:44:57,899 [2aaecf16-2d9d-1548-1429-543fa1c79243:frag:0:0] WARN
> o.a.d.e.w.fragment.FragmentExecutor - Ignoring unexpected state transition
> FAILED => CANCELLATION_REQUESTED.
> 2015-05-11 22:44:57,900 [2aaecf16-2d9d-1548-1429-543fa1c79243:frag:0:0] INFO
> o.a.drill.exec.work.foreman.Foreman - foreman cleaning up.
> 2015-05-11 22:44:57,910 [2aaecf16-2d9d-1548-1429-543fa1c79243:frag:0:0] ERROR
> o.a.d.exec.work.foreman.QueryManager - Failure while storing Query Profile
> java.lang.RuntimeException: java.io.IOException:
> java.lang.InterruptedException
> at
> org.apache.drill.exec.store.sys.local.FilePStore.put(FilePStore.java:148)
> ~[drill-java-exec-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
> at
> org.apache.drill.exec.work.foreman.QueryManager.writeFinalProfile(QueryManager.java:286)
> ~[drill-java-exec-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
> at
> org.apache.drill.exec.work.foreman.Foreman$ForemanResult.close(Foreman.java:731)
> [drill-java-exec-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
> at
> org.apache.drill.exec.work.foreman.Foreman$StateSwitch.processEvent(Foreman.java:826)
> [drill-java-exec-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
> at
> org.apache.drill.exec.work.foreman.Foreman$StateSwitch.processEvent(Foreman.java:768)
> [drill-java-exec-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
> at
> org.apache.drill.common.EventProcessor.s
[jira] [Updated] (DRILL-3027) Add convenience methods to test builder for creating nested baseline values
[ https://issues.apache.org/jira/browse/DRILL-3027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hanifi Gunes updated DRILL-3027: Assignee: Jason Altekruse (was: Hanifi Gunes) > Add convenience methods to test builder for creating nested baseline values > --- > > Key: DRILL-3027 > URL: https://issues.apache.org/jira/browse/DRILL-3027 > Project: Apache Drill > Issue Type: Improvement > Components: Tools, Build & Test >Affects Versions: 0.9.0 >Reporter: Hanifi Gunes >Assignee: Jason Altekruse > > When building a test case, we often need to create list instances to set > baseline values in Java space(as opposed to using baseline queries). This > issue proposes adding a static utility method TestBuilder#listOf(values) to > expedite process of creating lists. The same applies for maps such like > TestBuilder#mapOf(keyValueSequence) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (DRILL-3027) Add convenience methods to test builder for creating nested baseline values
[ https://issues.apache.org/jira/browse/DRILL-3027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hanifi Gunes reassigned DRILL-3027: --- Assignee: Hanifi Gunes (was: Jason Altekruse) > Add convenience methods to test builder for creating nested baseline values > --- > > Key: DRILL-3027 > URL: https://issues.apache.org/jira/browse/DRILL-3027 > Project: Apache Drill > Issue Type: Improvement > Components: Tools, Build & Test >Affects Versions: 0.9.0 >Reporter: Hanifi Gunes >Assignee: Hanifi Gunes > > When building a test case, we often need to create list instances to set > baseline values in Java space(as opposed to using baseline queries). This > issue proposes adding a static utility method TestBuilder#listOf(values) to > expedite process of creating lists. The same applies for maps such like > TestBuilder#mapOf(keyValueSequence) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-2977) In WorkManager, startFragmentPendingRemote() and addFragmentRunner() need to be permuted
[
https://issues.apache.org/jira/browse/DRILL-2977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheesh Katkam updated DRILL-2977:
---
Attachment: DRILL-2977.4.patch.txt
> In WorkManager, startFragmentPendingRemote() and addFragmentRunner() need to
> be permuted
>
>
> Key: DRILL-2977
> URL: https://issues.apache.org/jira/browse/DRILL-2977
> Project: Apache Drill
> Issue Type: Bug
> Components: Execution - Flow
>Reporter: Deneche A. Hakim
>Assignee: Venki Korukanti
> Fix For: 1.0.0
>
> Attachments: DRILL-2977.2.patch.txt, DRILL-2977.3.patch.txt,
> DRILL-2977.4.patch.txt
>
>
> In WorkManager 2 methods can be used to start a fragment executor:
> - startFragmentPendingRemote(FragmentManager) will start running a fragment
> by calling executor.execute(fragment)
> - addFragmentRunner(FragmentExecutor) will add the fragment to
> runningFragments and start a fragment after wrapping it inside a
> SelfCleanableRunner to make sure it's manager is removed from the
> WorkEventBus once finished.
> Looking at how both methods are called it seems that we are actually calling
> startFragmentPendingRemote() for fragments that were added to the
> WorkEventBus and we call addFragmentRunner() for fragment that were not added
> to the workBus!!! For example in Foreman.setupRootFragment() we have the
> following:
> {code}
> if (buffers.isDone()) {
> // if we don't have to wait for any incoming data, start the fragment
> runner.
> bee.addFragmentRunner(fragmentManager.getRunnable());
> } else {
> // if we do, record the fragment manager in the workBus.
> drillbitContext.getWorkBus().addFragmentManager(fragmentManager);
> }
> {code}
> The names of the methods are correct, but we need to switch their
> implementations
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DRILL-2998) Update C++ client to send/receive heartbeat message
[ https://issues.apache.org/jira/browse/DRILL-2998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Nadeau updated DRILL-2998: -- Priority: Major (was: Critical) > Update C++ client to send/receive heartbeat message > > > Key: DRILL-2998 > URL: https://issues.apache.org/jira/browse/DRILL-2998 > Project: Apache Drill > Issue Type: Bug > Components: Client - C++ >Reporter: Parth Chandra >Assignee: Parth Chandra > Fix For: 1.0.0 > > > See DRILL-2971. The RPC protocol now implements a heartbeat mechanism. The > C++ client needs to be updated to send and receive the heartbeat messages. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (DRILL-3029) Wrong result with correlated not exists subquery
Victoria Markman created DRILL-3029:
---
Summary: Wrong result with correlated not exists subquery
Key: DRILL-3029
URL: https://issues.apache.org/jira/browse/DRILL-3029
Project: Apache Drill
Issue Type: Bug
Components: Query Planning & Optimization
Affects Versions: 1.0.0
Reporter: Victoria Markman
Assignee: Jinfeng Ni
Priority: Critical
Subquery has correlation to two outer tables in the previous blocks.
Postgres returns empty result set in this case:
{code}
0: jdbc:drill:schema=dfs> select
. . . . . . . . . . . . > distinct a1
. . . . . . . . . . . . > from
. . . . . . . . . . . . > t1
. . . . . . . . . . . . > where not exists
. . . . . . . . . . . . > (
. . . . . . . . . . . . > select
. . . . . . . . . . . . > *
. . . . . . . . . . . . > from
. . . . . . . . . . . . > t2
. . . . . . . . . . . . > where not exists
. . . . . . . . . . . . > (
. . . . . . . . . . . . > select
. . . . . . . . . . . . > *
. . . . . . . . . . . . > from
. . . . . . . . . . . . > t3
. . . . . . . . . . . . > where
. . . . . . . . . . . . > t3.b3 = t2.b2 and
. . . . . . . . . . . . > t3.a3 = t1.a1
. . . . . . . . . . . . > )
. . . . . . . . . . . . > )
. . . . . . . . . . . . > ;
++
| a1 |
++
| 1 |
| 2 |
| 3 |
| 4 |
| 5 |
| 6 |
| 7 |
| 9 |
| 10 |
| null |
++
10 rows selected (0.991 seconds)
{code}
Copy/paste reproduction:
{code}
select
distinct a1
from
t1
where not exists
(
select
*
from
t2
where not exists
(
select
*
from
t3
where
t3.b3 = t2.b2 and
t3.a3 = t1.a1
)
)
;
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DRILL-3028) Exception in correlated subquery with exists when columns in subquery are not qualified
[
https://issues.apache.org/jira/browse/DRILL-3028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Victoria Markman updated DRILL-3028:
Description:
{code}
0: jdbc:drill:schema=dfs> select a1 from t1 where exists ( select * from t2
where b1 = b2 and a1 > a2) order by a1;
Error: SYSTEM ERROR: java.lang.NumberFormatException: zzz
Fragment 0:0
[Error Id: 2f13436c-048c-4a19-b99b-9d60a8d6bcf4 on atsqa4-133.qa.lab:31010]
(state=,code=0)
{code}
If you qualify columns, query works and returns correct result:
{code}
0: jdbc:drill:schema=dfs> select a1 from t1 where exists ( select * from t2
where t1.b1 = t2.b2 and t1.a1 > t2.a2) order by a1;
++
| a1 |
++
++
No rows selected (1.338 seconds)
{code}
>From drillbit.log
{code}
2015-05-11 22:44:57,895 [2aaecf16-2d9d-1548-1429-543fa1c79243:frag:0:0] INFO
o.a.drill.exec.work.foreman.Foreman - State change requested. RUNNING -->
FAILED
org.apache.drill.common.exceptions.UserRemoteException: SYSTEM ERROR:
java.lang.NumberFormatException: zzz
Fragment 0:0
[Error Id: 3fbdfc29-3fef-4968-b163-dbdefd45cdc6 on atsqa4-133.qa.lab:31010]
at
org.apache.drill.exec.work.foreman.QueryManager$1.statusUpdate(QueryManager.java:460)
[drill-java-exec-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
at
org.apache.drill.exec.work.foreman.QueryManager$RootStatusReporter.statusChange(QueryManager.java:440)
[drill-java-exec-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
at
org.apache.drill.exec.work.fragment.AbstractStatusReporter.fail(AbstractStatusReporter.java:90)
[drill-java-exec-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
at
org.apache.drill.exec.work.fragment.AbstractStatusReporter.fail(AbstractStatusReporter.java:86)
[drill-java-exec-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
at
org.apache.drill.exec.work.fragment.FragmentExecutor.sendFinalState(FragmentExecutor.java:290)
[drill-java-exec-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
at
org.apache.drill.exec.work.fragment.FragmentExecutor.run(FragmentExecutor.java:254)
[drill-java-exec-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
at
org.apache.drill.common.SelfCleaningRunnable.run(SelfCleaningRunnable.java:38)
[drill-common-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
[na:1.7.0_71]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
[na:1.7.0_71]
at java.lang.Thread.run(Thread.java:745) [na:1.7.0_71]
2015-05-11 22:44:57,899 [2aaecf16-2d9d-1548-1429-543fa1c79243:frag:0:0] INFO
o.a.d.e.w.fragment.FragmentExecutor - 2aaecf16-2d9d-1548-1429-543fa1c79243:0:0:
State change requested from FAILED --> CANCELLATION_REQUESTED for
2015-05-11 22:44:57,899 [2aaecf16-2d9d-1548-1429-543fa1c79243:frag:0:0] WARN
o.a.d.e.w.fragment.FragmentExecutor - Ignoring unexpected state transition
FAILED => CANCELLATION_REQUESTED.
2015-05-11 22:44:57,900 [2aaecf16-2d9d-1548-1429-543fa1c79243:frag:0:0] INFO
o.a.drill.exec.work.foreman.Foreman - foreman cleaning up.
2015-05-11 22:44:57,910 [2aaecf16-2d9d-1548-1429-543fa1c79243:frag:0:0] ERROR
o.a.d.exec.work.foreman.QueryManager - Failure while storing Query Profile
java.lang.RuntimeException: java.io.IOException: java.lang.InterruptedException
at
org.apache.drill.exec.store.sys.local.FilePStore.put(FilePStore.java:148)
~[drill-java-exec-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
at
org.apache.drill.exec.work.foreman.QueryManager.writeFinalProfile(QueryManager.java:286)
~[drill-java-exec-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
at
org.apache.drill.exec.work.foreman.Foreman$ForemanResult.close(Foreman.java:731)
[drill-java-exec-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
at
org.apache.drill.exec.work.foreman.Foreman$StateSwitch.processEvent(Foreman.java:826)
[drill-java-exec-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
at
org.apache.drill.exec.work.foreman.Foreman$StateSwitch.processEvent(Foreman.java:768)
[drill-java-exec-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
at
org.apache.drill.common.EventProcessor.sendEvent(EventProcessor.java:73)
[drill-common-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
at
org.apache.drill.exec.work.foreman.Foreman$StateSwitch.moveToState(Foreman.java:770)
[drill-java-exec-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
at
org.apache.drill.exec.work.foreman.Foreman.moveToState(Foreman.java:871)
[drill-java-exec-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
at
org.apache.drill.exec.work.foreman.Foreman.access$2700(Foreman.java:107)
[drill-java-exec-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
at
org.apache.drill.exec.work.foreman.Foreman$StateListener.moveToState(Foreman.java:1132)
[drill-java-exec-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
at
org.apache.drill.e
[jira] [Updated] (DRILL-3027) Add convenience methods to test builder for creating nested baseline values
[ https://issues.apache.org/jira/browse/DRILL-3027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hanifi Gunes updated DRILL-3027: Fix Version/s: 1.0.0 > Add convenience methods to test builder for creating nested baseline values > --- > > Key: DRILL-3027 > URL: https://issues.apache.org/jira/browse/DRILL-3027 > Project: Apache Drill > Issue Type: Improvement > Components: Tools, Build & Test >Affects Versions: 0.9.0 >Reporter: Hanifi Gunes >Assignee: Hanifi Gunes > Fix For: 1.0.0 > > > When building a test case, we often need to create list instances to set > baseline values in Java space(as opposed to using baseline queries). This > issue proposes adding a static utility method TestBuilder#listOf(values) to > expedite process of creating lists. The same applies for maps such like > TestBuilder#mapOf(keyValueSequence) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DRILL-3028) Exception in correlated subquery with exists when columns in subquery are not qualified
[
https://issues.apache.org/jira/browse/DRILL-3028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14538895#comment-14538895
]
Jinfeng Ni commented on DRILL-3028:
---
The query with qualification is actually different from the one w/o
qualification.
{code}
select a1 from t1 where exists ( select * from t2 where b1 = b2 and a1 > a2)
order by a1;
{code}
Drill is currently schema-less for parquet input. That means, the planner does
not know b1 belongs to t1, not t2. Actually, the planner will resolve b1 as t2,
since within that naming scope, t2 is the closet.
Therefore, the query is equivalent to
{code}
select a1 from t1 where exists ( select * from t2 where t2.b1 = t2.b2 and t2.a1
> t2.a2) order by a1;
{code}
Since t2.b1 does not exists (?), Drill treats it as nullable-int, and hence
implicit cast kicks in to do a int comparison. That's probably why you see
java.lang.NumberFormatException, because the input "zzz" is not a valid number.
Therefore, seems to me the behavior is expected.
> Exception in correlated subquery with exists when columns in subquery are not
> qualified
> ---
>
> Key: DRILL-3028
> URL: https://issues.apache.org/jira/browse/DRILL-3028
> Project: Apache Drill
> Issue Type: Bug
> Components: Query Planning & Optimization
>Affects Versions: 1.0.0
>Reporter: Victoria Markman
>Assignee: Jinfeng Ni
> Attachments: t1.parquet, t2.parquet
>
>
> {code}
> 0: jdbc:drill:schema=dfs> select a1 from t1 where exists ( select * from t2
> where b1 = b2 and a1 > a2) order by a1;
> Error: SYSTEM ERROR: java.lang.NumberFormatException: zzz
> Fragment 0:0
> [Error Id: 2f13436c-048c-4a19-b99b-9d60a8d6bcf4 on atsqa4-133.qa.lab:31010]
> (state=,code=0)
> {code}
> If you qualify columns, query works and returns correct result:
> {code}
> 0: jdbc:drill:schema=dfs> select a1 from t1 where exists ( select * from t2
> where t1.b1 = t2.b2 and t1.a1 > t2.a2) order by a1;
> ++
> | a1 |
> ++
> ++
> No rows selected (1.338 seconds)
> {code}
> From drillbit.log
> {code}
> 2015-05-11 22:44:57,895 [2aaecf16-2d9d-1548-1429-543fa1c79243:frag:0:0] INFO
> o.a.drill.exec.work.foreman.Foreman - State change requested. RUNNING -->
> FAILED
> org.apache.drill.common.exceptions.UserRemoteException: SYSTEM ERROR:
> java.lang.NumberFormatException: zzz
> Fragment 0:0
> [Error Id: 3fbdfc29-3fef-4968-b163-dbdefd45cdc6 on atsqa4-133.qa.lab:31010]
> at
> org.apache.drill.exec.work.foreman.QueryManager$1.statusUpdate(QueryManager.java:460)
> [drill-java-exec-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
> at
> org.apache.drill.exec.work.foreman.QueryManager$RootStatusReporter.statusChange(QueryManager.java:440)
> [drill-java-exec-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
> at
> org.apache.drill.exec.work.fragment.AbstractStatusReporter.fail(AbstractStatusReporter.java:90)
> [drill-java-exec-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
> at
> org.apache.drill.exec.work.fragment.AbstractStatusReporter.fail(AbstractStatusReporter.java:86)
> [drill-java-exec-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
> at
> org.apache.drill.exec.work.fragment.FragmentExecutor.sendFinalState(FragmentExecutor.java:290)
> [drill-java-exec-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
> at
> org.apache.drill.exec.work.fragment.FragmentExecutor.run(FragmentExecutor.java:254)
> [drill-java-exec-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
> at
> org.apache.drill.common.SelfCleaningRunnable.run(SelfCleaningRunnable.java:38)
> [drill-common-1.0.0-SNAPSHOT-rebuffed.jar:1.0.0-SNAPSHOT]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> [na:1.7.0_71]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> [na:1.7.0_71]
> at java.lang.Thread.run(Thread.java:745) [na:1.7.0_71]
> 2015-05-11 22:44:57,899 [2aaecf16-2d9d-1548-1429-543fa1c79243:frag:0:0] INFO
> o.a.d.e.w.fragment.FragmentExecutor -
> 2aaecf16-2d9d-1548-1429-543fa1c79243:0:0: State change requested from FAILED
> --> CANCELLATION_REQUESTED for
> 2015-05-11 22:44:57,899 [2aaecf16-2d9d-1548-1429-543fa1c79243:frag:0:0] WARN
> o.a.d.e.w.fragment.FragmentExecutor - Ignoring unexpected state transition
> FAILED => CANCELLATION_REQUESTED.
> 2015-05-11 22:44:57,900 [2aaecf16-2d9d-1548-1429-543fa1c79243:frag:0:0] INFO
> o.a.drill.exec.work.foreman.Foreman - foreman cleaning up.
> 2015-05-11 22:44:57,910 [2aaecf16-2d9d-1548-1429-543fa1c79243:frag:0:0] ERROR
> o.a.d.exec.work.foreman.QueryManager - Failure while storing Query Profile
> java.lang.RuntimeException: java.io.IOException:
> java.lang.InterruptedException
>
[jira] [Updated] (DRILL-2476) Handle IterOutcome.STOP in buildSchema()
[
https://issues.apache.org/jira/browse/DRILL-2476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheesh Katkam updated DRILL-2476:
---
Attachment: DRILL-2476.3.patch.txt
> Handle IterOutcome.STOP in buildSchema()
>
>
> Key: DRILL-2476
> URL: https://issues.apache.org/jira/browse/DRILL-2476
> Project: Apache Drill
> Issue Type: Bug
> Components: Execution - Relational Operators
>Affects Versions: 0.7.0
>Reporter: Sudheesh Katkam
>Assignee: Steven Phillips
> Fix For: 1.0.0
>
> Attachments: DRILL-2476.1.patch.txt, DRILL-2476.2.patch.txt,
> DRILL-2476.3.patch.txt
>
>
> There are some {{RecordBatch}} implementations like {{HashAggBatch}} that
> override the {{buildSchema()}} function. The overriding functions do not
> handle {{IterOutcome.STOP}}. This causes the {{FragmentContext}} to receive
> two failures in some cases (linked JIRAs).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DRILL-2953) Group By + Order By query results are not ordered.
[
https://issues.apache.org/jira/browse/DRILL-2953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14538914#comment-14538914
]
Aman Sinha commented on DRILL-2953:
---
Will this work for something like: ORDER BY a, CAST(b), c ?
Here, it would be incorrect to have a collation on {a, c} i.e skipping the
middle CAST(b).
> Group By + Order By query results are not ordered.
> --
>
> Key: DRILL-2953
> URL: https://issues.apache.org/jira/browse/DRILL-2953
> Project: Apache Drill
> Issue Type: Bug
> Components: Query Planning & Optimization
>Affects Versions: 0.9.0
> Environment: 10833d2cae9f5312cf0e31f8c9f3f8a9dcdc0c45 | Commit 0.9.0
> release version. | 03.05.2015 @ 14:56:56 EDT
>Reporter: Khurram Faraaz
>Assignee: Jinfeng Ni
>Priority: Critical
> Fix For: 1.0.0
>
> Attachments:
> 0001-DRILL-2953-Ensure-sort-would-be-enforced-when-a-cast.patch
>
>
> Group by + order by query does not return results in correct order. Sort is
> performed before the aggregation is done, which should not be the case.
> Test was performed on 4 node cluster on CentOS.
> {code}
> 0: jdbc:drill:> select cast(columns[0] as int) c1 from `testWindow.csv` t2
> where t2.columns[0] is not null group by columns[0] order by columns[0];
> ++
> | c1 |
> ++
> | 10 |
> | 100|
> | 113|
> | 119|
> | 2 |
> | 50 |
> | 55 |
> | 57 |
> | 61 |
> | 67 |
> | 89 |
> ++
> 11 rows selected (0.218 seconds)
> {code}
> Explain plan for that query that returns wrong results.
> {code}
> 0: jdbc:drill:> explain plan for select cast(columns[0] as int) c1 from
> `testWindow.csv` t2 where t2.columns[0] is not null group by columns[0] order
> by columns[0];
> +++
> |text|json|
> +++
> | 00-00Screen
> 00-01 Project(c1=[$0])
> 00-02Project(c1=[CAST($0):INTEGER], EXPR$1=[$0])
> 00-03 StreamAgg(group=[{0}])
> 00-04Sort(sort0=[$0], dir0=[ASC])
> 00-05 Filter(condition=[IS NOT NULL($0)])
> 00-06Project(ITEM=[ITEM($0, 0)])
> 00-07 Scan(groupscan=[EasyGroupScan
> [selectionRoot=/tmp/testWindow.csv, numFiles=1, columns=[`columns`[0]],
> files=[maprfs:/tmp/testWindow.csv]]])
> {code}
> Incorrect results , not in order.
> {code}
> 0: jdbc:drill:> select cast(columns[0] as int) from `testWindow.csv` t2 where
> t2.columns[0] is not null group by columns[0] order by columns[0];
> ++
> | EXPR$0 |
> ++
> | 10 |
> | 100|
> | 113|
> | 119|
> | 2 |
> | 50 |
> | 55 |
> | 57 |
> | 61 |
> | 67 |
> | 89 |
> ++
> 11 rows selected (0.214 seconds)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (DRILL-3030) Foreman seems to be unable to cancel itself
Ramana Inukonda Nagaraj created DRILL-3030:
--
Summary: Foreman seems to be unable to cancel itself
Key: DRILL-3030
URL: https://issues.apache.org/jira/browse/DRILL-3030
Project: Apache Drill
Issue Type: Bug
Components: Execution - Flow
Affects Versions: 1.0.0
Reporter: Ramana Inukonda Nagaraj
Assignee: Chris Westin
Steps to repro:
1. Ran long running query on a clean drill restart.
2. Killed a non foreman node.
3. Restarted drillbits using clush.
One of the drillbits(coincidentally a foreman node always) refused to shutdown.
Jstack shows that the foreman is waiting
{code}
at
org.apache.drill.exec.rpc.ReconnectingConnection$ConnectionListeningFuture.waitAndRun(ReconnectingConnection.java:105)
at
org.apache.drill.exec.rpc.ReconnectingConnection.runCommand(ReconnectingConnection.java:81)
- locked <0x00073878aaa8> (a
org.apache.drill.exec.rpc.control.ControlConnectionManager)
at
org.apache.drill.exec.rpc.control.ControlTunnel.cancelFragment(ControlTunnel.java:57)
at
org.apache.drill.exec.work.foreman.QueryManager.cancelExecutingFragments(QueryManager.java:192)
at
org.apache.drill.exec.work.foreman.Foreman$StateSwitch.processEvent(Foreman.java:824)
at
org.apache.drill.exec.work.foreman.Foreman$StateSwitch.processEvent(Foreman.java:768)
at
org.apache.drill.common.EventProcessor.sendEvent(EventProcessor.java:73)
at
org.apache.drill.exec.work.foreman.Foreman$StateSwitch.moveToState(Foreman.java:770)
at
org.apache.drill.exec.work.foreman.Foreman.moveToState(Foreman.java:871)
at
org.apache.drill.exec.work.foreman.Foreman.access$2700(Foreman.java:107)
at
org.apache.drill.exec.work.foreman.Foreman$StateListener.moveToState(Foreman.java:1132)
at
org.apache.drill.exec.work.foreman.QueryManager$1.statusUpdate(QueryManager.java:460)
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DRILL-3030) Foreman seems to be unable to cancel itself
[
https://issues.apache.org/jira/browse/DRILL-3030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ramana Inukonda Nagaraj updated DRILL-3030:
---
Attachment: threadstack
Jstack of hanging foreman node.
> Foreman seems to be unable to cancel itself
> ---
>
> Key: DRILL-3030
> URL: https://issues.apache.org/jira/browse/DRILL-3030
> Project: Apache Drill
> Issue Type: Bug
> Components: Execution - Flow
>Affects Versions: 1.0.0
>Reporter: Ramana Inukonda Nagaraj
>Assignee: Chris Westin
> Attachments: threadstack
>
>
> Steps to repro:
> 1. Ran long running query on a clean drill restart.
> 2. Killed a non foreman node.
> 3. Restarted drillbits using clush.
> One of the drillbits(coincidentally a foreman node always) refused to
> shutdown.
> Jstack shows that the foreman is waiting
> {code}
> at
> org.apache.drill.exec.rpc.ReconnectingConnection$ConnectionListeningFuture.waitAndRun(ReconnectingConnection.java:105)
> at
> org.apache.drill.exec.rpc.ReconnectingConnection.runCommand(ReconnectingConnection.java:81)
> - locked <0x00073878aaa8> (a
> org.apache.drill.exec.rpc.control.ControlConnectionManager)
> at
> org.apache.drill.exec.rpc.control.ControlTunnel.cancelFragment(ControlTunnel.java:57)
> at
> org.apache.drill.exec.work.foreman.QueryManager.cancelExecutingFragments(QueryManager.java:192)
> at
> org.apache.drill.exec.work.foreman.Foreman$StateSwitch.processEvent(Foreman.java:824)
> at
> org.apache.drill.exec.work.foreman.Foreman$StateSwitch.processEvent(Foreman.java:768)
> at
> org.apache.drill.common.EventProcessor.sendEvent(EventProcessor.java:73)
> at
> org.apache.drill.exec.work.foreman.Foreman$StateSwitch.moveToState(Foreman.java:770)
> at
> org.apache.drill.exec.work.foreman.Foreman.moveToState(Foreman.java:871)
> at
> org.apache.drill.exec.work.foreman.Foreman.access$2700(Foreman.java:107)
> at
> org.apache.drill.exec.work.foreman.Foreman$StateListener.moveToState(Foreman.java:1132)
> at
> org.apache.drill.exec.work.foreman.QueryManager$1.statusUpdate(QueryManager.java:460)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DRILL-2953) Group By + Order By query results are not ordered.
[
https://issues.apache.org/jira/browse/DRILL-2953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14538939#comment-14538939
]
Jinfeng Ni commented on DRILL-2953:
---
Skipping the middle CAST(b) means the output of project will not have the
sort-ness of a, cast(b), c, then the down-stream operator has to insert a SORT
enforcer to get the sort-ness it requires.
Tried the following cases. Both the plan looks fine:
1)
{code}
select cast(columns[0] as int) as nation_key
from
dfs_test.`file:/Users/jni/work/incubator-drill/exec/java-exec/target/test-classes/store/text/data/nations.csv`
group by columns[0], columns[1], columns[2]
order by columns[0], cast(columns[1] as int), columns[2]
{code}
Plan:
{code}
00-00Screen
00-01 Project(nation_key=[$0])
00-02SelectionVectorRemover
00-03 Sort(sort0=[$1], sort1=[$2], sort2=[$3], dir0=[ASC], dir1=[ASC],
dir2=[ASC])
00-04Project(nation_key=[CAST($0):INTEGER], EXPR$1=[$0],
EXPR$2=[CAST($1):INTEGER], EXPR$3=[$2])
00-05 StreamAgg(group=[{0, 1, 2}])
00-06Sort(sort0=[$0], sort1=[$1], sort2=[$2], dir0=[ASC],
dir1=[ASC], dir2=[ASC])
00-07 Project($f0=[ITEM($0, 0)], $f1=[ITEM($0, 1)],
$f2=[ITEM($0, 2)])
00-08Scan(groupscan=[EasyGroupScan
[selectionRoot=/Users/jni/work/incubator-drill/exec/java-exec/target/test-classes/store/text/data/nations.csv,
numFiles=1, columns=[`columns`[0], `columns`[1], `columns`[2]],
files=[file:/Users/jni/work/incubator-drill/exec/java-exec/target/test-classes/store/text/data/nations.csv]]])
{code}
2)
{code}
select cast(columns[0] as int) as nation_key
from
dfs_test.`file:/Users/jni/work/incubator-drill/exec/java-exec/target/test-classes/store/text/data/nations.csv`
group by columns[0], columns[1], columns[2]
order by columns[0], columns[2]
{code}
Plan:
{code}
00-00Screen
00-01 Project(nation_key=[$0])
00-02SelectionVectorRemover
00-03 Sort(sort0=[$1], sort1=[$2], dir0=[ASC], dir1=[ASC])
00-04Project(nation_key=[CAST($0):INTEGER], EXPR$1=[$0],
EXPR$2=[$2])
00-05 StreamAgg(group=[{0, 1, 2}])
00-06Sort(sort0=[$0], sort1=[$1], sort2=[$2], dir0=[ASC],
dir1=[ASC], dir2=[ASC])
00-07 Project($f0=[ITEM($0, 0)], $f1=[ITEM($0, 1)],
$f2=[ITEM($0, 2)])
00-08Scan(groupscan=[EasyGroupScan
[selectionRoot=/Users/jni/work/incubator-drill/exec/java-exec/target/test-classes/store/text/data/nations.csv,
numFiles=1, columns=[`columns`[0], `columns`[1], `columns`[2]],
files=[file:/Users/jni/work/incubator-drill/exec/java-exec/target/test-classes/store/text/data/nations.csv]]])
{code}
In the above two cases, a sort is inserted to ensure the sort-ness specified by
the ORDERBY clause.
> Group By + Order By query results are not ordered.
> --
>
> Key: DRILL-2953
> URL: https://issues.apache.org/jira/browse/DRILL-2953
> Project: Apache Drill
> Issue Type: Bug
> Components: Query Planning & Optimization
>Affects Versions: 0.9.0
> Environment: 10833d2cae9f5312cf0e31f8c9f3f8a9dcdc0c45 | Commit 0.9.0
> release version. | 03.05.2015 @ 14:56:56 EDT
>Reporter: Khurram Faraaz
>Assignee: Jinfeng Ni
>Priority: Critical
> Fix For: 1.0.0
>
> Attachments:
> 0001-DRILL-2953-Ensure-sort-would-be-enforced-when-a-cast.patch
>
>
> Group by + order by query does not return results in correct order. Sort is
> performed before the aggregation is done, which should not be the case.
> Test was performed on 4 node cluster on CentOS.
> {code}
> 0: jdbc:drill:> select cast(columns[0] as int) c1 from `testWindow.csv` t2
> where t2.columns[0] is not null group by columns[0] order by columns[0];
> ++
> | c1 |
> ++
> | 10 |
> | 100|
> | 113|
> | 119|
> | 2 |
> | 50 |
> | 55 |
> | 57 |
> | 61 |
> | 67 |
> | 89 |
> ++
> 11 rows selected (0.218 seconds)
> {code}
> Explain plan for that query that returns wrong results.
> {code}
> 0: jdbc:drill:> explain plan for select cast(columns[0] as int) c1 from
> `testWindow.csv` t2 where t2.columns[0] is not null group by columns[0] order
> by columns[0];
> +++
> |text|json|
> +++
> | 00-00Screen
> 00-01 Project(c1=[$0])
> 00-02Project(c1=[CAST($0):INTEGER], EXPR$1=[$0])
> 00-03 StreamAgg(group=[{0}])
> 00-04Sort(sort0=[$0], dir0=[ASC])
> 00-05 Filter(condition=[IS NOT NULL($0)])
> 00-06Project(ITEM=[ITEM($0, 0)])
> 00-07 Scan(groupscan=[EasyGroupScan
> [selectionRoot=/tmp/testWind
[jira] [Commented] (DRILL-3030) Foreman seems to be unable to cancel itself
[
https://issues.apache.org/jira/browse/DRILL-3030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14538941#comment-14538941
]
Ramana Inukonda Nagaraj commented on DRILL-3030:
Few more observations:
>From the logs it looks like the fragment executing at the foreman node has not
>received a cancellation request.
> Foreman seems to be unable to cancel itself
> ---
>
> Key: DRILL-3030
> URL: https://issues.apache.org/jira/browse/DRILL-3030
> Project: Apache Drill
> Issue Type: Bug
> Components: Execution - Flow
>Affects Versions: 1.0.0
>Reporter: Ramana Inukonda Nagaraj
>Assignee: Chris Westin
> Attachments: threadstack
>
>
> Steps to repro:
> 1. Ran long running query on a clean drill restart.
> 2. Killed a non foreman node.
> 3. Restarted drillbits using clush.
> One of the drillbits(coincidentally a foreman node always) refused to
> shutdown.
> Jstack shows that the foreman is waiting
> {code}
> at
> org.apache.drill.exec.rpc.ReconnectingConnection$ConnectionListeningFuture.waitAndRun(ReconnectingConnection.java:105)
> at
> org.apache.drill.exec.rpc.ReconnectingConnection.runCommand(ReconnectingConnection.java:81)
> - locked <0x00073878aaa8> (a
> org.apache.drill.exec.rpc.control.ControlConnectionManager)
> at
> org.apache.drill.exec.rpc.control.ControlTunnel.cancelFragment(ControlTunnel.java:57)
> at
> org.apache.drill.exec.work.foreman.QueryManager.cancelExecutingFragments(QueryManager.java:192)
> at
> org.apache.drill.exec.work.foreman.Foreman$StateSwitch.processEvent(Foreman.java:824)
> at
> org.apache.drill.exec.work.foreman.Foreman$StateSwitch.processEvent(Foreman.java:768)
> at
> org.apache.drill.common.EventProcessor.sendEvent(EventProcessor.java:73)
> at
> org.apache.drill.exec.work.foreman.Foreman$StateSwitch.moveToState(Foreman.java:770)
> at
> org.apache.drill.exec.work.foreman.Foreman.moveToState(Foreman.java:871)
> at
> org.apache.drill.exec.work.foreman.Foreman.access$2700(Foreman.java:107)
> at
> org.apache.drill.exec.work.foreman.Foreman$StateListener.moveToState(Foreman.java:1132)
> at
> org.apache.drill.exec.work.foreman.QueryManager$1.statusUpdate(QueryManager.java:460)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DRILL-3021) Exception in a JDBC session causes the client connection to be closed
[ https://issues.apache.org/jira/browse/DRILL-3021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14538968#comment-14538968 ] Kunal Khatua commented on DRILL-3021: - Exception was reported by Aman during a SqlLine session, when he encountered a CannotPlanException. For me, concurrent execution of queries results in some queries timing out. For this, the JDBC client issues query cancel on the statement object. All queries issued after this on the same session/connection fail with the above CONNECTION ERROR message. > Exception in a JDBC session causes the client connection to be closed > - > > Key: DRILL-3021 > URL: https://issues.apache.org/jira/browse/DRILL-3021 > Project: Apache Drill > Issue Type: Bug > Components: Client - JDBC >Affects Versions: 1.0.0 > Environment: RHEL 6.4 >Reporter: Kunal Khatua >Assignee: Daniel Barclay (Drill) > Fix For: 1.0.0 > > > When running a lot of queries in a session (one connection), if an exception > is encountered or if the client cancels the query (due to its internal > timeout), the following exception is thrown for subsequent queries being > submitted. > Error: CONNECTION ERROR: Connection null <--> null (user client) closed > unexpectedly. > 2015-05-10 18:21:33 [pip2] ERROR PipSQuawkling executeQuery - [ 6 / 10_par100 > ] CONNECTION ERROR: Connection null <--> null (user client) closed > unexpectedly. > [Error Id: a57768ad-a6ab-4f83-a1c9-381d127600b3 ] > java.sql.SQLException: CONNECTION ERROR: Connection null <--> null (user > client) closed unexpectedly. > [Error Id: a57768ad-a6ab-4f83-a1c9-381d127600b3 ] > at org.apache.drill.jdbc.DrillCursor.next(DrillCursor.java:161) > at > org.apache.drill.jdbc.impl.DrillResultSetImpl.execute(DrillResultSetImpl.java:167) > at > org.apache.drill.jdbc.impl.DrillResultSetImpl.execute(DrillResultSetImpl.java:56) > at > net.hydromatic.avatica.AvaticaConnection.executeQueryInternal(AvaticaConnection.java:404) > at > net.hydromatic.avatica.AvaticaStatement.executeQueryInternal(AvaticaStatement.java:351) > at > net.hydromatic.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:78) > at > org.apache.drill.jdbc.DrillStatement.executeQuery(DrillStatement.java:81) > at PipSQuawkling.executeQuery(PipSQuawkling.java:295) > at PipSQuawkling.executeTest(PipSQuawkling.java:148) > at PipSQuawkling.run(PipSQuawkling.java:76) > Caused by: org.apache.drill.common.exceptions.UserException: CONNECTION > ERROR: Connection null <--> null (user client) closed unexpectedly. > [Error Id: a57768ad-a6ab-4f83-a1c9-381d127600b3 ] > at > org.apache.drill.common.exceptions.UserException$Builder.build(UserException.java:495) > at > org.apache.drill.exec.rpc.user.QueryResultHandler$SubmissionListener$ChannelClosedListener.operationComplete(QueryResultHandler.java:298) > at > io.netty.util.concurrent.DefaultPromise.notifyListener0(DefaultPromise.java:680) > at > io.netty.util.concurrent.DefaultPromise$LateListeners.run(DefaultPromise.java:845) > at > io.netty.util.concurrent.DefaultPromise$LateListenerNotifier.run(DefaultPromise.java:873) > at > io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:357) > at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:357) > at > io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:111) > at java.lang.Thread.run(Thread.java:744) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DRILL-2953) Group By + Order By query results are not ordered.
[
https://issues.apache.org/jira/browse/DRILL-2953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14538988#comment-14538988
]
Jinfeng Ni commented on DRILL-2953:
---
One more case:
{code}
select cast(columns[0] as int) as nation_key from
dfs_test.`file:/Users/jni/work/incubator-drill/exec/java-exec/target/test-classes/store/text/data/nations.csv`
group by columns[0], cast(columns[1] as int), columns[2] order by
columns[0], columns[2]
textjson
00-00Screen
00-01 Project(nation_key=[$0])
00-02SelectionVectorRemover
00-03 Sort(sort0=[$1], sort1=[$2], dir0=[ASC], dir1=[ASC])
00-04Project(nation_key=[CAST($0):INTEGER], EXPR$1=[$0],
EXPR$2=[$2])
00-05 StreamAgg(group=[{0, 1, 2}])
00-06Sort(sort0=[$0], sort1=[$1], sort2=[$2], dir0=[ASC],
dir1=[ASC], dir2=[ASC])
00-07 Project($f0=[ITEM($0, 0)], $f1=[CAST(ITEM($0,
1)):INTEGER], $f2=[ITEM($0, 2)])
00-08Scan(groupscan=
{code}
> Group By + Order By query results are not ordered.
> --
>
> Key: DRILL-2953
> URL: https://issues.apache.org/jira/browse/DRILL-2953
> Project: Apache Drill
> Issue Type: Bug
> Components: Query Planning & Optimization
>Affects Versions: 0.9.0
> Environment: 10833d2cae9f5312cf0e31f8c9f3f8a9dcdc0c45 | Commit 0.9.0
> release version. | 03.05.2015 @ 14:56:56 EDT
>Reporter: Khurram Faraaz
>Assignee: Jinfeng Ni
>Priority: Critical
> Fix For: 1.0.0
>
> Attachments:
> 0001-DRILL-2953-Ensure-sort-would-be-enforced-when-a-cast.patch
>
>
> Group by + order by query does not return results in correct order. Sort is
> performed before the aggregation is done, which should not be the case.
> Test was performed on 4 node cluster on CentOS.
> {code}
> 0: jdbc:drill:> select cast(columns[0] as int) c1 from `testWindow.csv` t2
> where t2.columns[0] is not null group by columns[0] order by columns[0];
> ++
> | c1 |
> ++
> | 10 |
> | 100|
> | 113|
> | 119|
> | 2 |
> | 50 |
> | 55 |
> | 57 |
> | 61 |
> | 67 |
> | 89 |
> ++
> 11 rows selected (0.218 seconds)
> {code}
> Explain plan for that query that returns wrong results.
> {code}
> 0: jdbc:drill:> explain plan for select cast(columns[0] as int) c1 from
> `testWindow.csv` t2 where t2.columns[0] is not null group by columns[0] order
> by columns[0];
> +++
> |text|json|
> +++
> | 00-00Screen
> 00-01 Project(c1=[$0])
> 00-02Project(c1=[CAST($0):INTEGER], EXPR$1=[$0])
> 00-03 StreamAgg(group=[{0}])
> 00-04Sort(sort0=[$0], dir0=[ASC])
> 00-05 Filter(condition=[IS NOT NULL($0)])
> 00-06Project(ITEM=[ITEM($0, 0)])
> 00-07 Scan(groupscan=[EasyGroupScan
> [selectionRoot=/tmp/testWindow.csv, numFiles=1, columns=[`columns`[0]],
> files=[maprfs:/tmp/testWindow.csv]]])
> {code}
> Incorrect results , not in order.
> {code}
> 0: jdbc:drill:> select cast(columns[0] as int) from `testWindow.csv` t2 where
> t2.columns[0] is not null group by columns[0] order by columns[0];
> ++
> | EXPR$0 |
> ++
> | 10 |
> | 100|
> | 113|
> | 119|
> | 2 |
> | 50 |
> | 55 |
> | 57 |
> | 61 |
> | 67 |
> | 89 |
> ++
> 11 rows selected (0.214 seconds)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DRILL-2560) JDBC execute calls return asynchronously for DDLs
[ https://issues.apache.org/jira/browse/DRILL-2560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14538993#comment-14538993 ] Daniel Barclay (Drill) commented on DRILL-2560: --- JDBC Note: Where JDBC documentation somewhat circularly defines things in terms of "if ... returns a ResultSet" (referring to the physical Java object), it apparently really means "if ... returns a result set" (the logical SQL object). > JDBC execute calls return asynchronously for DDLs > - > > Key: DRILL-2560 > URL: https://issues.apache.org/jira/browse/DRILL-2560 > Project: Apache Drill > Issue Type: Bug > Components: Client - JDBC >Affects Versions: 0.8.0 >Reporter: Chris Westin >Assignee: Daniel Barclay (Drill) > Fix For: 1.1.0 > > > While working with TestViews, I noticed that JDBC's executeQuery() returns > immediately for drop view statements. For DDLs, users' expectation would be > that the call would return synchronously. The same would be true for > execute(), and executeUpdate(), if used for DDLs. This behavior is pretty > typical for RDBMSs. This avoids the user having to consume the (non-)output > in order to wait for the statement to complete -- otherwise it will get > cancelled when the Statement is closed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (DRILL-2776) querying a .json file that contains a repeated type returns the wrong results
[
https://issues.apache.org/jira/browse/DRILL-2776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hanifi Gunes resolved DRILL-2776.
-
Resolution: Fixed
Fixed by 27b4aae2008a8125411eb0ec23a07cad8cea096e
> querying a .json file that contains a repeated type returns the wrong results
> --
>
> Key: DRILL-2776
> URL: https://issues.apache.org/jira/browse/DRILL-2776
> Project: Apache Drill
> Issue Type: Bug
> Components: Execution - Data Types
>Affects Versions: 0.8.0
>Reporter: Deneche A. Hakim
>Assignee: Hanifi Gunes
>Priority: Critical
> Fix For: 1.0.0
>
>
> I have the following .json file:
> {code}
> {"bag":[]}
> {"bag":[1]}
> {code}
> doing a select star on it returns the following results:
> {noformat}
> 0: jdbc:drill:zk=local> select * from dfs.data.`t.json`;
> ++
> |bag |
> ++
> | [] |
> | null |
> ++
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (DRILL-3031) Project missing a column (empty repeated type)
Rahul Challapalli created DRILL-3031:
Summary: Project missing a column (empty repeated type)
Key: DRILL-3031
URL: https://issues.apache.org/jira/browse/DRILL-3031
Project: Apache Drill
Issue Type: Bug
Components: Execution - Flow
Reporter: Rahul Challapalli
Assignee: Hanifi Gunes
git.commit.id.abbrev=4689468
Data :
{code}
{"id":1, "arr":[]}
{code}
Query :
{code}
0: jdbc:drill:schema=dfs_eea> select * from `file1.json`;
++
| id |
++
| 1 |
++
1 row selected (0.131 seconds)
{code}
Drill did not report the second column here.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DRILL-3031) Project missing a column (empty repeated type)
[
https://issues.apache.org/jira/browse/DRILL-3031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14539006#comment-14539006
]
Rahul Challapalli commented on DRILL-3031:
--
Data:
{code}
{"arr":[]}
{code}
Query :
{code}
0: jdbc:drill:schema=dfs_eea> select * from `file2.json`;
++
| * |
++
| null |
++
{code}
> Project missing a column (empty repeated type)
> --
>
> Key: DRILL-3031
> URL: https://issues.apache.org/jira/browse/DRILL-3031
> Project: Apache Drill
> Issue Type: Bug
> Components: Execution - Flow
>Reporter: Rahul Challapalli
>Assignee: Hanifi Gunes
>
> git.commit.id.abbrev=4689468
> Data :
> {code}
> {"id":1, "arr":[]}
> {code}
> Query :
> {code}
> 0: jdbc:drill:schema=dfs_eea> select * from `file1.json`;
> ++
> | id |
> ++
> | 1 |
> ++
> 1 row selected (0.131 seconds)
> {code}
> Drill did not report the second column here.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DRILL-2953) Group By + Order By query results are not ordered.
[
https://issues.apache.org/jira/browse/DRILL-2953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14539020#comment-14539020
]
Aman Sinha commented on DRILL-2953:
---
Yes, the plans look good, adding the sort after the streaming aggregate.
+1 .
> Group By + Order By query results are not ordered.
> --
>
> Key: DRILL-2953
> URL: https://issues.apache.org/jira/browse/DRILL-2953
> Project: Apache Drill
> Issue Type: Bug
> Components: Query Planning & Optimization
>Affects Versions: 0.9.0
> Environment: 10833d2cae9f5312cf0e31f8c9f3f8a9dcdc0c45 | Commit 0.9.0
> release version. | 03.05.2015 @ 14:56:56 EDT
>Reporter: Khurram Faraaz
>Assignee: Jinfeng Ni
>Priority: Critical
> Fix For: 1.0.0
>
> Attachments:
> 0001-DRILL-2953-Ensure-sort-would-be-enforced-when-a-cast.patch
>
>
> Group by + order by query does not return results in correct order. Sort is
> performed before the aggregation is done, which should not be the case.
> Test was performed on 4 node cluster on CentOS.
> {code}
> 0: jdbc:drill:> select cast(columns[0] as int) c1 from `testWindow.csv` t2
> where t2.columns[0] is not null group by columns[0] order by columns[0];
> ++
> | c1 |
> ++
> | 10 |
> | 100|
> | 113|
> | 119|
> | 2 |
> | 50 |
> | 55 |
> | 57 |
> | 61 |
> | 67 |
> | 89 |
> ++
> 11 rows selected (0.218 seconds)
> {code}
> Explain plan for that query that returns wrong results.
> {code}
> 0: jdbc:drill:> explain plan for select cast(columns[0] as int) c1 from
> `testWindow.csv` t2 where t2.columns[0] is not null group by columns[0] order
> by columns[0];
> +++
> |text|json|
> +++
> | 00-00Screen
> 00-01 Project(c1=[$0])
> 00-02Project(c1=[CAST($0):INTEGER], EXPR$1=[$0])
> 00-03 StreamAgg(group=[{0}])
> 00-04Sort(sort0=[$0], dir0=[ASC])
> 00-05 Filter(condition=[IS NOT NULL($0)])
> 00-06Project(ITEM=[ITEM($0, 0)])
> 00-07 Scan(groupscan=[EasyGroupScan
> [selectionRoot=/tmp/testWindow.csv, numFiles=1, columns=[`columns`[0]],
> files=[maprfs:/tmp/testWindow.csv]]])
> {code}
> Incorrect results , not in order.
> {code}
> 0: jdbc:drill:> select cast(columns[0] as int) from `testWindow.csv` t2 where
> t2.columns[0] is not null group by columns[0] order by columns[0];
> ++
> | EXPR$0 |
> ++
> | 10 |
> | 100|
> | 113|
> | 119|
> | 2 |
> | 50 |
> | 55 |
> | 57 |
> | 61 |
> | 67 |
> | 89 |
> ++
> 11 rows selected (0.214 seconds)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DRILL-2560) JDBC execute calls return asynchronously for DDLs
[
https://issues.apache.org/jira/browse/DRILL-2560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14539021#comment-14539021
]
Daniel Barclay (Drill) commented on DRILL-2560:
---
SQL specification notes:
_Apparently_, which SQL statements return results sets and which do not is
defined via :
ISO-8075:2011 Part 2 Section 14.3, "", says:
{quote}
Function
Define a result set.
{quote}
Therefore, again apparently, any SQL statement whose syntax includes is a statement that returns a result set, and other statements
are not.
(A starts with a . A leads to , , or
. A JDBC execute calls return asynchronously for DDLs
> -
>
> Key: DRILL-2560
> URL: https://issues.apache.org/jira/browse/DRILL-2560
> Project: Apache Drill
> Issue Type: Bug
> Components: Client - JDBC
>Affects Versions: 0.8.0
>Reporter: Chris Westin
>Assignee: Daniel Barclay (Drill)
> Fix For: 1.1.0
>
>
> While working with TestViews, I noticed that JDBC's executeQuery() returns
> immediately for drop view statements. For DDLs, users' expectation would be
> that the call would return synchronously. The same would be true for
> execute(), and executeUpdate(), if used for DDLs. This behavior is pretty
> typical for RDBMSs. This avoids the user having to consume the (non-)output
> in order to wait for the statement to complete -- otherwise it will get
> cancelled when the Statement is closed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (DRILL-2560) JDBC execute calls return asynchronously for DDLs
[
https://issues.apache.org/jira/browse/DRILL-2560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14539021#comment-14539021
]
Daniel Barclay (Drill) edited comment on DRILL-2560 at 5/12/15 1:04 AM:
SQL specification notes:
_Apparently_, which SQL statements return results sets and which do not is
defined via :
ISO-8075:2011 Part 2 Section 14.3, "", says:
{quote}
Function
Define a result set.
{quote}
Therefore, again apparently, any SQL statement whose syntax includes is a statement that returns a result set, and other statements
are not.
(Well, includes , and only declaring a
cursor presumably does not actually return a result by itself, so the paragraph
above is only a first approximation.)
(A starts with a . A leads to , , or
. A :
ISO-8075:2011 Part 2 Section 14.3, "", says:
{quote}
Function
Define a result set.
{quote}
Therefore, again apparently, any SQL statement whose syntax includes is a statement that returns a result set, and other statements
are not.
(A starts with a . A leads to , , or
. A JDBC execute calls return asynchronously for DDLs
> -
>
> Key: DRILL-2560
> URL: https://issues.apache.org/jira/browse/DRILL-2560
> Project: Apache Drill
> Issue Type: Bug
> Components: Client - JDBC
>Affects Versions: 0.8.0
>Reporter: Chris Westin
>Assignee: Daniel Barclay (Drill)
> Fix For: 1.1.0
>
>
> While working with TestViews, I noticed that JDBC's executeQuery() returns
> immediately for drop view statements. For DDLs, users' expectation would be
> that the call would return synchronously. The same would be true for
> execute(), and executeUpdate(), if used for DDLs. This behavior is pretty
> typical for RDBMSs. This avoids the user having to consume the (non-)output
> in order to wait for the statement to complete -- otherwise it will get
> cancelled when the Statement is closed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DRILL-2229) SQL syntax errors should use SQLSyntaxErrorException
[ https://issues.apache.org/jira/browse/DRILL-2229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14539040#comment-14539040 ] Aman Sinha commented on DRILL-2229: --- +1 > SQL syntax errors should use SQLSyntaxErrorException > > > Key: DRILL-2229 > URL: https://issues.apache.org/jira/browse/DRILL-2229 > Project: Apache Drill > Issue Type: Bug > Components: SQL Parser >Reporter: Daniel Barclay (Drill) >Assignee: Aman Sinha > Fix For: 1.2.0 > > Attachments: DRILL-2229.1.patch > > > SQL syntax errors should be reported with SQLSyntaxErrorException (or > subclasses, of course) rather than SQLException (in part so that when they > get to the JDBC interface they can be reported at intended using > SQLSyntaxErrorException . -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (DRILL-2982) Tableau 9.0 Server Enablement Documentation
[ https://issues.apache.org/jira/browse/DRILL-2982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bob Rumsby resolved DRILL-2982. --- Resolution: Fixed Target Version/s: 1.0.0 Document pushed to Tomer's staging site. > Tableau 9.0 Server Enablement Documentation > --- > > Key: DRILL-2982 > URL: https://issues.apache.org/jira/browse/DRILL-2982 > Project: Apache Drill > Issue Type: Improvement > Components: Documentation >Affects Versions: 0.9.0, 1.0.0 >Reporter: Andries Engelbrecht >Assignee: Bob Rumsby > Attachments: Tableau 9 Server Drill Configuration.docx > > > Tableau 9.0 Server Enablement document -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (DRILL-2229) SQL syntax errors should use SQLSyntaxErrorException
[ https://issues.apache.org/jira/browse/DRILL-2229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14539040#comment-14539040 ] Aman Sinha edited comment on DRILL-2229 at 5/12/15 1:22 AM: +1 for the patch. Can you pls add couple of examples of the error message after the patch: - parse error - unsupported operation exception was (Author: amansinha100): +1 > SQL syntax errors should use SQLSyntaxErrorException > > > Key: DRILL-2229 > URL: https://issues.apache.org/jira/browse/DRILL-2229 > Project: Apache Drill > Issue Type: Bug > Components: SQL Parser >Reporter: Daniel Barclay (Drill) >Assignee: Aman Sinha > Fix For: 1.2.0 > > Attachments: DRILL-2229.1.patch > > > SQL syntax errors should be reported with SQLSyntaxErrorException (or > subclasses, of course) rather than SQLException (in part so that when they > get to the JDBC interface they can be reported at intended using > SQLSyntaxErrorException . -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DRILL-2229) SQL syntax errors should use SQLSyntaxErrorException
[ https://issues.apache.org/jira/browse/DRILL-2229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14539073#comment-14539073 ] Sean Hsuan-Yi Chu commented on DRILL-2229: -- 1. Parser Error: (1). select n_nationkey where n_nationkey >= 2 org.apache.drill.common.exceptions.UserRemoteException: PARSE ERROR: Encountered "where" at line 1, column 22. (2). select n_nationkey from cp.`tpch/nation.parquet` group by n_name org.apache.drill.common.exceptions.UserRemoteException: PARSE ERROR: From line 1, column 8 to line 1, column 18: Expression 'n_nationkey' is not being grouped 2. Unsupported Operation: (1). select * from cp.`tpch/nation.parquet`, cp.`tpch/region.parquet` org.apache.drill.common.exceptions.UserRemoteException: UNSUPPORTED_OPERATION ERROR: This query cannot be planned possibly due to either a cartesian join or an inequality join (2). select cast(n_nationkey as TINYINT ) from cp.`tpch/nation.parquet` org.apache.drill.common.exceptions.UserRemoteException: UNSUPPORTED_OPERATION ERROR: TINYINT is not supported See Apache Drill JIRA: DRILL-1959 > SQL syntax errors should use SQLSyntaxErrorException > > > Key: DRILL-2229 > URL: https://issues.apache.org/jira/browse/DRILL-2229 > Project: Apache Drill > Issue Type: Bug > Components: SQL Parser >Reporter: Daniel Barclay (Drill) >Assignee: Aman Sinha > Fix For: 1.2.0 > > Attachments: DRILL-2229.1.patch > > > SQL syntax errors should be reported with SQLSyntaxErrorException (or > subclasses, of course) rather than SQLException (in part so that when they > get to the JDBC interface they can be reported at intended using > SQLSyntaxErrorException . -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (DRILL-3032) Join between complex (nested repeated lists) data results in "LATE type is not supported"
Rahul Challapalli created DRILL-3032:
Summary: Join between complex (nested repeated lists) data results
in "LATE type is not supported"
Key: DRILL-3032
URL: https://issues.apache.org/jira/browse/DRILL-3032
Project: Apache Drill
Issue Type: Bug
Reporter: Rahul Challapalli
git.commit.id.abbrev=4689468
Data Set 1 :
{code}
{
"id":1,
"aaa":[[["aa0 1"], ["ab0 1"]]]
}
{code}
Data Set 2 :
{code}
{"id" : 1}
{code}
The below query fails
{code}
0: jdbc:drill:schema=dfs_eea> select * from `file1.json` f1 inner join
`file2.json` f2 on f1.id = f2.id;
Error: SYSTEM ERROR: java.lang.UnsupportedOperationException: LATE type is not
supported. Mode: OPTIONAL
Fragment 0:0
[Error Id: a865954d-dd29-42fc-8538-291a835a79cd on qa-node190.qa.lab:31010]
(state=,code=0)
{code}
Attached the error logs
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DRILL-3032) Join between complex (nested repeated lists) data results in "LATE type is not supported"
[
https://issues.apache.org/jira/browse/DRILL-3032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rahul Challapalli updated DRILL-3032:
-
Attachment: error.log
> Join between complex (nested repeated lists) data results in "LATE type is
> not supported"
> -
>
> Key: DRILL-3032
> URL: https://issues.apache.org/jira/browse/DRILL-3032
> Project: Apache Drill
> Issue Type: Bug
> Components: Execution - Flow
>Reporter: Rahul Challapalli
> Attachments: error.log
>
>
> git.commit.id.abbrev=4689468
> Data Set 1 :
> {code}
> {
> "id":1,
> "aaa":[[["aa0 1"], ["ab0 1"]]]
> }
> {code}
> Data Set 2 :
> {code}
> {"id" : 1}
> {code}
> The below query fails
> {code}
> 0: jdbc:drill:schema=dfs_eea> select * from `file1.json` f1 inner join
> `file2.json` f2 on f1.id = f2.id;
> Error: SYSTEM ERROR: java.lang.UnsupportedOperationException: LATE type is
> not supported. Mode: OPTIONAL
> Fragment 0:0
> [Error Id: a865954d-dd29-42fc-8538-291a835a79cd on qa-node190.qa.lab:31010]
> (state=,code=0)
> {code}
> Attached the error logs
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DRILL-3032) Join between complex (nested repeated lists) data results in "LATE type is not supported"
[
https://issues.apache.org/jira/browse/DRILL-3032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rahul Challapalli updated DRILL-3032:
-
Component/s: Execution - Flow
Assignee: Hanifi Gunes
> Join between complex (nested repeated lists) data results in "LATE type is
> not supported"
> -
>
> Key: DRILL-3032
> URL: https://issues.apache.org/jira/browse/DRILL-3032
> Project: Apache Drill
> Issue Type: Bug
> Components: Execution - Flow
>Reporter: Rahul Challapalli
>Assignee: Hanifi Gunes
> Attachments: error.log
>
>
> git.commit.id.abbrev=4689468
> Data Set 1 :
> {code}
> {
> "id":1,
> "aaa":[[["aa0 1"], ["ab0 1"]]]
> }
> {code}
> Data Set 2 :
> {code}
> {"id" : 1}
> {code}
> The below query fails
> {code}
> 0: jdbc:drill:schema=dfs_eea> select * from `file1.json` f1 inner join
> `file2.json` f2 on f1.id = f2.id;
> Error: SYSTEM ERROR: java.lang.UnsupportedOperationException: LATE type is
> not supported. Mode: OPTIONAL
> Fragment 0:0
> [Error Id: a865954d-dd29-42fc-8538-291a835a79cd on qa-node190.qa.lab:31010]
> (state=,code=0)
> {code}
> Attached the error logs
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (DRILL-3033) Add memory leak fixes found so far in DRILL-1942 to 1.0
Chris Westin created DRILL-3033: --- Summary: Add memory leak fixes found so far in DRILL-1942 to 1.0 Key: DRILL-3033 URL: https://issues.apache.org/jira/browse/DRILL-3033 Project: Apache Drill Issue Type: Bug Components: Execution - Flow Affects Versions: 0.9.0 Reporter: Chris Westin Assignee: Chris Westin Fix For: 1.0.0 The new memory allocator being implemented for DRILL-1942 has found a number of leaks. But the complete allocator patch isn't ready yet. However, in order to increase the stability of 1.0, we're going to include just the changes for leaks found so far using the new allocator. This ticket tracks that. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (DRILL-3034) Apply UserException to port-binding error; handle UserException in embedded-Drill case
Daniel Barclay (Drill) created DRILL-3034: - Summary: Apply UserException to port-binding error; handle UserException in embedded-Drill case Key: DRILL-3034 URL: https://issues.apache.org/jira/browse/DRILL-3034 Project: Apache Drill Issue Type: Bug Reporter: Daniel Barclay (Drill) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (DRILL-3034) Apply UserException to port-binding error; handle UserException in embedded-Drill case
[ https://issues.apache.org/jira/browse/DRILL-3034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Barclay (Drill) reassigned DRILL-3034: - Assignee: Daniel Barclay (Drill) > Apply UserException to port-binding error; handle UserException in > embedded-Drill case > -- > > Key: DRILL-3034 > URL: https://issues.apache.org/jira/browse/DRILL-3034 > Project: Apache Drill > Issue Type: Bug >Reporter: Daniel Barclay (Drill) >Assignee: Daniel Barclay (Drill) > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-3034) Apply UserException to port-binding error; handle UserException in embedded-Drill case
[ https://issues.apache.org/jira/browse/DRILL-3034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Barclay (Drill) updated DRILL-3034: -- Priority: Minor (was: Major) > Apply UserException to port-binding error; handle UserException in > embedded-Drill case > -- > > Key: DRILL-3034 > URL: https://issues.apache.org/jira/browse/DRILL-3034 > Project: Apache Drill > Issue Type: Bug >Reporter: Daniel Barclay (Drill) >Assignee: Daniel Barclay (Drill) >Priority: Minor > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-3034) Apply UserException to port-binding error; handle UserException in embedded-Drill case
[ https://issues.apache.org/jira/browse/DRILL-3034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Barclay (Drill) updated DRILL-3034: -- Attachment: DRILL-3034.1.patch.txt > Apply UserException to port-binding error; handle UserException in > embedded-Drill case > -- > > Key: DRILL-3034 > URL: https://issues.apache.org/jira/browse/DRILL-3034 > Project: Apache Drill > Issue Type: Bug >Reporter: Daniel Barclay (Drill) >Assignee: Daniel Barclay (Drill) >Priority: Minor > Attachments: DRILL-3034.1.patch.txt > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DRILL-3034) Apply UserException to port-binding error; handle UserException in embedded-Drill case
[ https://issues.apache.org/jira/browse/DRILL-3034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14539205#comment-14539205 ] Daniel Barclay (Drill) commented on DRILL-3034: --- DRILL-3034's patch depends on DRILL-3020's patch. > Apply UserException to port-binding error; handle UserException in > embedded-Drill case > -- > > Key: DRILL-3034 > URL: https://issues.apache.org/jira/browse/DRILL-3034 > Project: Apache Drill > Issue Type: Bug >Reporter: Daniel Barclay (Drill) >Assignee: Daniel Barclay (Drill) >Priority: Minor > Attachments: DRILL-3034.1.patch.txt > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-3034) Apply UserException to port-binding error; handle UserException in embedded-Drill case
[ https://issues.apache.org/jira/browse/DRILL-3034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Barclay (Drill) updated DRILL-3034: -- Component/s: Execution - RPC Client - JDBC > Apply UserException to port-binding error; handle UserException in > embedded-Drill case > -- > > Key: DRILL-3034 > URL: https://issues.apache.org/jira/browse/DRILL-3034 > Project: Apache Drill > Issue Type: Bug > Components: Client - JDBC, Execution - RPC >Reporter: Daniel Barclay (Drill) >Assignee: Daniel Barclay (Drill) >Priority: Minor > Attachments: DRILL-3034.1.patch.txt > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DRILL-3034) Apply UserException to port-binding error; handle UserException in embedded-Drill case
[ https://issues.apache.org/jira/browse/DRILL-3034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14539217#comment-14539217 ] Daniel Barclay (Drill) commented on DRILL-3034: --- This also clarifies from (approximately) "Cannot bind Drillbit" to "Drill cannot bind to port xxx". > Apply UserException to port-binding error; handle UserException in > embedded-Drill case > -- > > Key: DRILL-3034 > URL: https://issues.apache.org/jira/browse/DRILL-3034 > Project: Apache Drill > Issue Type: Bug > Components: Client - JDBC, Execution - RPC >Reporter: Daniel Barclay (Drill) >Assignee: Daniel Barclay (Drill) >Priority: Minor > Attachments: DRILL-3034.1.patch.txt > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (DRILL-3034) Apply UserException to port-binding error; handle UserException in embedded-Drill case
[ https://issues.apache.org/jira/browse/DRILL-3034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14539217#comment-14539217 ] Daniel Barclay (Drill) edited comment on DRILL-3034 at 5/12/15 4:38 AM: This also clarifies from "Could not bind Drillbit" to "Drillbit could not bind to port 31010.". was (Author: dsbos): This also clarifies from (approximately) "Cannot bind Drillbit" to "Drill cannot bind to port xxx". > Apply UserException to port-binding error; handle UserException in > embedded-Drill case > -- > > Key: DRILL-3034 > URL: https://issues.apache.org/jira/browse/DRILL-3034 > Project: Apache Drill > Issue Type: Bug > Components: Client - JDBC, Execution - RPC >Reporter: Daniel Barclay (Drill) >Assignee: Daniel Barclay (Drill) >Priority: Minor > Attachments: DRILL-3034.1.patch.txt > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-1980) Create table with a Cast to interval day results in a file which cannot be read
[
https://issues.apache.org/jira/browse/DRILL-1980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mehant Baid updated DRILL-1980:
---
Attachment: DRILL-1980.patch
[~jaltekruse] please review≈
> Create table with a Cast to interval day results in a file which cannot be
> read
> ---
>
> Key: DRILL-1980
> URL: https://issues.apache.org/jira/browse/DRILL-1980
> Project: Apache Drill
> Issue Type: Bug
> Components: Storage - Parquet
>Affects Versions: 0.7.0
>Reporter: Ramana Inukonda Nagaraj
>Assignee: Mehant Baid
> Fix For: 1.0.0
>
> Attachments: DRILL-1980.patch, alltypes.json,
> parquet_all_types.parquet
>
>
> Created a parquet file from a json file with all types listed in it.
> {code}
> 0: jdbc:drill:> CREATE TABLE parquet_all_types AS SELECT cast( INT_col as
> int) INT_col,cast( BIGINT_col as bigint) BIGINT_col,cast( DECIMAL9_col as
> decimal) DECIMAL9_col,cast( DECIMAL18_col as decimal(18,9))
> DECIMAL18_col,cast( DECIMAL28SPARSE_col as decimal(28, 14))
> DECIMAL28SPARSE_col,cast( DECIMAL38SPARSE_col as decimal(38, 19))
> DECIMAL38SPARSE_col,cast( DATE_col as date) DATE_col,cast( TIME_col as time)
> TIME_col,cast( TIMESTAMP_col as timestamp) TIMESTAMP_col,cast( FLOAT4_col as
> float) FLOAT4_col,cast( FLOAT8_col as double) FLOAT8_col,cast( BIT_col as
> boolean) BIT_col,cast( VARCHAR_col as varchar(65000)) VARCHAR_col,cast(
> VAR16CHAR_col as varchar(65000)) VAR16CHAR_col,cast( VARBINARY_col as
> varbinary(65000)) VARBINARY_col,cast( INTERVALYEAR_col as interval year)
> INTERVALYEAR_col,cast( INTERVALDAY_col as interval day) INTERVALDAY_col FROM
> `/user/root/alltypes.json`;
> ++---+
> | Fragment | Number of records written |
> ++---+
> | 0_0| 8 |
> ++---+
> 1 row selected (0.595 seconds)
> {code}
> Tried reading created parquet file from drill. Fails with
> {code}
> 0: jdbc:drill:> explain plan for select * from
> `/parquet_all_types/0_0_0.parquet`;
> Query failed: Query failed: Unexpected exception during fragment
> initialization: Internal error: Error while applying rule DrillTableRule,
> args [rel#6060:EnumerableTableAccessRel.ENUMERABLE.ANY([]).[](table=[dfs,
> root, /parquet_all_types/0_0_0.parquet])]
> Error: exception while executing query: Failure while executing query.
> (state=,code=0)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DRILL-1980) Create table with a Cast to interval day results in a file which cannot be read
[
https://issues.apache.org/jira/browse/DRILL-1980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mehant Baid updated DRILL-1980:
---
Assignee: Jason Altekruse (was: Mehant Baid)
> Create table with a Cast to interval day results in a file which cannot be
> read
> ---
>
> Key: DRILL-1980
> URL: https://issues.apache.org/jira/browse/DRILL-1980
> Project: Apache Drill
> Issue Type: Bug
> Components: Storage - Parquet
>Affects Versions: 0.7.0
>Reporter: Ramana Inukonda Nagaraj
>Assignee: Jason Altekruse
> Fix For: 1.0.0
>
> Attachments: DRILL-1980.patch, alltypes.json,
> parquet_all_types.parquet
>
>
> Created a parquet file from a json file with all types listed in it.
> {code}
> 0: jdbc:drill:> CREATE TABLE parquet_all_types AS SELECT cast( INT_col as
> int) INT_col,cast( BIGINT_col as bigint) BIGINT_col,cast( DECIMAL9_col as
> decimal) DECIMAL9_col,cast( DECIMAL18_col as decimal(18,9))
> DECIMAL18_col,cast( DECIMAL28SPARSE_col as decimal(28, 14))
> DECIMAL28SPARSE_col,cast( DECIMAL38SPARSE_col as decimal(38, 19))
> DECIMAL38SPARSE_col,cast( DATE_col as date) DATE_col,cast( TIME_col as time)
> TIME_col,cast( TIMESTAMP_col as timestamp) TIMESTAMP_col,cast( FLOAT4_col as
> float) FLOAT4_col,cast( FLOAT8_col as double) FLOAT8_col,cast( BIT_col as
> boolean) BIT_col,cast( VARCHAR_col as varchar(65000)) VARCHAR_col,cast(
> VAR16CHAR_col as varchar(65000)) VAR16CHAR_col,cast( VARBINARY_col as
> varbinary(65000)) VARBINARY_col,cast( INTERVALYEAR_col as interval year)
> INTERVALYEAR_col,cast( INTERVALDAY_col as interval day) INTERVALDAY_col FROM
> `/user/root/alltypes.json`;
> ++---+
> | Fragment | Number of records written |
> ++---+
> | 0_0| 8 |
> ++---+
> 1 row selected (0.595 seconds)
> {code}
> Tried reading created parquet file from drill. Fails with
> {code}
> 0: jdbc:drill:> explain plan for select * from
> `/parquet_all_types/0_0_0.parquet`;
> Query failed: Query failed: Unexpected exception during fragment
> initialization: Internal error: Error while applying rule DrillTableRule,
> args [rel#6060:EnumerableTableAccessRel.ENUMERABLE.ANY([]).[](table=[dfs,
> root, /parquet_all_types/0_0_0.parquet])]
> Error: exception while executing query: Failure while executing query.
> (state=,code=0)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (DRILL-3035) Create ControlsInjector interface to enforce implementing methods
Sudheesh Katkam created DRILL-3035: -- Summary: Create ControlsInjector interface to enforce implementing methods Key: DRILL-3035 URL: https://issues.apache.org/jira/browse/DRILL-3035 Project: Apache Drill Issue Type: Bug Reporter: Sudheesh Katkam Assignee: Sudheesh Katkam Fix For: 1.0.0 Extract all injector methods into an interface so ExecutionControlsInjector and NoOpControlsInjector are forced to implement the methods to avoid potential NPEs when assertions are disabled. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (DRILL-2998) Update C++ client to send/receive heartbeat message
[ https://issues.apache.org/jira/browse/DRILL-2998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Parth Chandra reassigned DRILL-2998: Assignee: Hanifi Gunes (was: Parth Chandra) > Update C++ client to send/receive heartbeat message > > > Key: DRILL-2998 > URL: https://issues.apache.org/jira/browse/DRILL-2998 > Project: Apache Drill > Issue Type: Bug > Components: Client - C++ >Reporter: Parth Chandra >Assignee: Hanifi Gunes > Fix For: 1.0.0 > > Attachments: DRILL-2998-1.patch.txt > > > See DRILL-2971. The RPC protocol now implements a heartbeat mechanism. The > C++ client needs to be updated to send and receive the heartbeat messages. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-2998) Update C++ client to send/receive heartbeat message
[ https://issues.apache.org/jira/browse/DRILL-2998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Parth Chandra updated DRILL-2998: - Attachment: DRILL-2998-1.patch.txt > Update C++ client to send/receive heartbeat message > > > Key: DRILL-2998 > URL: https://issues.apache.org/jira/browse/DRILL-2998 > Project: Apache Drill > Issue Type: Bug > Components: Client - C++ >Reporter: Parth Chandra >Assignee: Parth Chandra > Fix For: 1.0.0 > > Attachments: DRILL-2998-1.patch.txt > > > See DRILL-2971. The RPC protocol now implements a heartbeat mechanism. The > C++ client needs to be updated to send and receive the heartbeat messages. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-3035) Create ControlsInjector interface to enforce implementing methods
[ https://issues.apache.org/jira/browse/DRILL-3035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudheesh Katkam updated DRILL-3035: --- Attachment: DRILL-3035.1.patch.txt > Create ControlsInjector interface to enforce implementing methods > - > > Key: DRILL-3035 > URL: https://issues.apache.org/jira/browse/DRILL-3035 > Project: Apache Drill > Issue Type: Bug >Reporter: Sudheesh Katkam >Assignee: Sudheesh Katkam > Fix For: 1.0.0 > > Attachments: DRILL-3035.1.patch.txt > > > Extract all injector methods into an interface so ExecutionControlsInjector > and NoOpControlsInjector are forced to implement the methods to avoid > potential NPEs when assertions are disabled. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DRILL-3023) Drill ODBC Connection not working - attached logs in the details
[ https://issues.apache.org/jira/browse/DRILL-3023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14539271#comment-14539271 ] Murtaza commented on DRILL-3023: Hi Parth, Please find the below step by step details on what I did - 1. Downloaded Apache drill from website and using URL => http://getdrill.org/drill/download/apache-drill-0.9.0.tar.gz 2. Downloaded Apache Drill ODBC driver using URL => http://package.mapr.com/tools/MapR-ODBC/MapR_Drill/MapRDrill_odbc_v0.09.0.0620/MapRDrillODBC32.msi http://package.mapr.com/tools/MapR-ODBC/MapR_Drill/MapRDrill_odbc_v0.09.0.0620/MapRDrillODBC64.msi 3. Install latest JDK version 1.7 on CentOS linux and confirmed it by typing - "java -version" 4. Untar apache-drill-0.9 on centos and executed below command to start Apache drill [root@kwtprdmsap001 apache-drill-0.9.0]# bin/sqlline -u jdbc:drill:zk=local May 11, 2015 8:26:53 AM org.glassfish.jersey.server.ApplicationHandler initialize INFO: Initiating Jersey application, version Jersey: 2.8 2014-04-29 01:25:26... sqlline version 1.1.6 0: jdbc:drill:zk=local> It started successfully and I could also check the Apache drill web console on http://kwtprdmsap001:8047 5. I installed 32 bit and 64 bit both ODBC drivers on my Windows 7 machine which is on the LAN network. I checked if DNS name kwtprdmsap001 can be resolved and it was giving me correct IP address. After installation, I went to ODBC32 Administrator as attached in the screenshot (attached in this JIRA). Please let me know what is wrong with the configuration? > Drill ODBC Connection not working - attached logs in the details > > > Key: DRILL-3023 > URL: https://issues.apache.org/jira/browse/DRILL-3023 > Project: Apache Drill > Issue Type: Bug > Components: Client - ODBC >Affects Versions: 0.9.0 >Reporter: Murtaza >Assignee: Parth Chandra >Priority: Critical > > Getting below error in the sqlline log file. > Apache Drill 0.9 is installed on CentOS 64bit, embedded drillbits. Trying to > access ODBC from Windows machine after installing ODBC 32bit & 64bit drivers, > both have same errors. > 2015-05-11 14:47:29,652 [UserServer-1] ERROR > o.a.drill.exec.rpc.user.UserServer - Error > 2845b981-804a-44d4-a9f1-88866f778c26 in Handling handshake request: > RPC_VERSION_MISMATCH, Invalid rpc version. Expected 5, actual 3. > 2015-05-11 14:47:29,653 [UserServer-1] ERROR > o.a.d.exec.rpc.RpcExceptionHandler - Exception in pipeline. Closing channel > between local /172.16.98.101:31010 and remote /10.16.17.114:61346 > io.netty.handler.codec.DecoderException: > org.apache.drill.exec.rpc.RpcException: Handshake request failed: Invalid rpc > version. Expected 5, actual 3. > at > io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:99) > [netty-codec-4.0.24.Final.jar:4.0.24.Final] > at > io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:333) > [netty-transport-4.0.24.Final.jar:4.0.24.Final] > at > io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:319) > [netty-transport-4.0.24.Final.jar:4.0.24.Final] > at > io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:103) > [netty-codec-4.0.24.Final.jar:4.0.24.Final] > at > io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:333) > [netty-transport-4.0.24.Final.jar:4.0.24.Final] > at > io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:319) > [netty-transport-4.0.24.Final.jar:4.0.24.Final] > at > io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:161) > [netty-codec-4.0.24.Final.jar:4.0.24.Final] > at > io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:333) > [netty-transport-4.0.24.Final.jar:4.0.24.Final] > at > io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:319) > [netty-transport-4.0.24.Final.jar:4.0.24.Final] > at > io.netty.channel.ChannelInboundHandlerAdapter.channelRead(ChannelInboundHandlerAdapter.java:86) > [netty-transport-4.0.24.Final.jar:4.0.24.Final] > at > io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:333) > [netty-transport-4.0.24.Final.jar:4.0.24.Final] > at > io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:319) > [netty-transport-4.0.24.Final.jar:4.0.24.Final] > at > io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelP
[jira] [Updated] (DRILL-3023) Drill ODBC Connection not working - attached logs in the details
[ https://issues.apache.org/jira/browse/DRILL-3023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Murtaza updated DRILL-3023: --- Attachment: screenshot-1.png > Drill ODBC Connection not working - attached logs in the details > > > Key: DRILL-3023 > URL: https://issues.apache.org/jira/browse/DRILL-3023 > Project: Apache Drill > Issue Type: Bug > Components: Client - ODBC >Affects Versions: 0.9.0 >Reporter: Murtaza >Assignee: Parth Chandra >Priority: Critical > Attachments: screenshot-1.png > > > Getting below error in the sqlline log file. > Apache Drill 0.9 is installed on CentOS 64bit, embedded drillbits. Trying to > access ODBC from Windows machine after installing ODBC 32bit & 64bit drivers, > both have same errors. > 2015-05-11 14:47:29,652 [UserServer-1] ERROR > o.a.drill.exec.rpc.user.UserServer - Error > 2845b981-804a-44d4-a9f1-88866f778c26 in Handling handshake request: > RPC_VERSION_MISMATCH, Invalid rpc version. Expected 5, actual 3. > 2015-05-11 14:47:29,653 [UserServer-1] ERROR > o.a.d.exec.rpc.RpcExceptionHandler - Exception in pipeline. Closing channel > between local /172.16.98.101:31010 and remote /10.16.17.114:61346 > io.netty.handler.codec.DecoderException: > org.apache.drill.exec.rpc.RpcException: Handshake request failed: Invalid rpc > version. Expected 5, actual 3. > at > io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:99) > [netty-codec-4.0.24.Final.jar:4.0.24.Final] > at > io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:333) > [netty-transport-4.0.24.Final.jar:4.0.24.Final] > at > io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:319) > [netty-transport-4.0.24.Final.jar:4.0.24.Final] > at > io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:103) > [netty-codec-4.0.24.Final.jar:4.0.24.Final] > at > io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:333) > [netty-transport-4.0.24.Final.jar:4.0.24.Final] > at > io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:319) > [netty-transport-4.0.24.Final.jar:4.0.24.Final] > at > io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:161) > [netty-codec-4.0.24.Final.jar:4.0.24.Final] > at > io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:333) > [netty-transport-4.0.24.Final.jar:4.0.24.Final] > at > io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:319) > [netty-transport-4.0.24.Final.jar:4.0.24.Final] > at > io.netty.channel.ChannelInboundHandlerAdapter.channelRead(ChannelInboundHandlerAdapter.java:86) > [netty-transport-4.0.24.Final.jar:4.0.24.Final] > at > io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:333) > [netty-transport-4.0.24.Final.jar:4.0.24.Final] > at > io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:319) > [netty-transport-4.0.24.Final.jar:4.0.24.Final] > at > io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:787) > [netty-transport-4.0.24.Final.jar:4.0.24.Final] > at > io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:130) > [netty-transport-4.0.24.Final.jar:4.0.24.Final] > at > io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:511) > [netty-transport-4.0.24.Final.jar:4.0.24.Final] > at > io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:468) > [netty-transport-4.0.24.Final.jar:4.0.24.Final] > at > io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:382) > [netty-transport-4.0.24.Final.jar:4.0.24.Final] > at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:354) > [netty-transport-4.0.24.Final.jar:4.0.24.Final] > at > io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:116) > [netty-common-4.0.24.Final.jar:4.0.24.Final] > at java.lang.Thread.run(Thread.java:745) [na:1.7.0_60] > Caused by: org.apache.drill.exec.rpc.RpcException: Handshake request failed: > Invalid rpc version. Expected 5, actual 3. > at > org.apache.drill.exec.rpc.user.UserServer$1.consumeHandshake(UserServer.java:181) > ~[drill-java-exec-0.9.0-rebuffed.jar:0.9.0] > at > org.apache.drill.exec.rpc.user.UserServer$1.consumeHandshake(Us
[jira] [Updated] (DRILL-3035) Create ControlsInjector interface to enforce implementing methods
[ https://issues.apache.org/jira/browse/DRILL-3035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudheesh Katkam updated DRILL-3035: --- Assignee: Venki Korukanti (was: Sudheesh Katkam) > Create ControlsInjector interface to enforce implementing methods > - > > Key: DRILL-3035 > URL: https://issues.apache.org/jira/browse/DRILL-3035 > Project: Apache Drill > Issue Type: Bug >Reporter: Sudheesh Katkam >Assignee: Venki Korukanti > Fix For: 1.0.0 > > Attachments: DRILL-3035.1.patch.txt > > > Extract all injector methods into an interface so ExecutionControlsInjector > and NoOpControlsInjector are forced to implement the methods to avoid > potential NPEs when assertions are disabled. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-3035) Create ControlsInjector interface to enforce implementing methods
[ https://issues.apache.org/jira/browse/DRILL-3035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudheesh Katkam updated DRILL-3035: --- Fix Version/s: (was: 1.0.0) 1.1.0 > Create ControlsInjector interface to enforce implementing methods > - > > Key: DRILL-3035 > URL: https://issues.apache.org/jira/browse/DRILL-3035 > Project: Apache Drill > Issue Type: Bug > Components: Execution - Flow >Reporter: Sudheesh Katkam >Assignee: Sudheesh Katkam > Fix For: 1.1.0 > > Attachments: DRILL-3035.1.patch.txt > > > Extract all injector methods into an interface so ExecutionControlsInjector > and NoOpControlsInjector are forced to implement the methods to avoid > potential NPEs when assertions are disabled. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-3035) Create ControlsInjector interface to enforce implementing methods
[ https://issues.apache.org/jira/browse/DRILL-3035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudheesh Katkam updated DRILL-3035: --- Component/s: Execution - Flow > Create ControlsInjector interface to enforce implementing methods > - > > Key: DRILL-3035 > URL: https://issues.apache.org/jira/browse/DRILL-3035 > Project: Apache Drill > Issue Type: Bug > Components: Execution - Flow >Reporter: Sudheesh Katkam >Assignee: Sudheesh Katkam > Fix For: 1.1.0 > > Attachments: DRILL-3035.1.patch.txt > > > Extract all injector methods into an interface so ExecutionControlsInjector > and NoOpControlsInjector are forced to implement the methods to avoid > potential NPEs when assertions are disabled. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-3035) Create ControlsInjector interface to enforce implementing methods
[ https://issues.apache.org/jira/browse/DRILL-3035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudheesh Katkam updated DRILL-3035: --- Assignee: Sudheesh Katkam (was: Venki Korukanti) > Create ControlsInjector interface to enforce implementing methods > - > > Key: DRILL-3035 > URL: https://issues.apache.org/jira/browse/DRILL-3035 > Project: Apache Drill > Issue Type: Bug > Components: Execution - Flow >Reporter: Sudheesh Katkam >Assignee: Sudheesh Katkam > Fix For: 1.1.0 > > Attachments: DRILL-3035.1.patch.txt > > > Extract all injector methods into an interface so ExecutionControlsInjector > and NoOpControlsInjector are forced to implement the methods to avoid > potential NPEs when assertions are disabled. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
