[jira] [Updated] (DRILL-4679) CONVERT_FROM() json format fails if 0 rows are received from upstream operator
[
https://issues.apache.org/jira/browse/DRILL-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Suresh Ollala updated DRILL-4679:
-
Reviewer: Chun Chang
> CONVERT_FROM() json format fails if 0 rows are received from upstream
> operator
> ---
>
> Key: DRILL-4679
> URL: https://issues.apache.org/jira/browse/DRILL-4679
> Project: Apache Drill
> Issue Type: Bug
> Components: Execution - Relational Operators
>Affects Versions: 1.6.0
>Reporter: Aman Sinha
>Assignee: Aman Sinha
> Fix For: 1.7.0
>
>
> CONVERT_FROM() json format fails as below if the underlying Filter produces 0
> rows:
> {noformat}
> 0: jdbc:drill:zk=local> select convert_from('{"abc":"xyz"}', 'json') as x
> from cp.`tpch/region.parquet` where r_regionkey = ;
> Error: SYSTEM ERROR: IllegalStateException: next() returned NONE without
> first returning OK_NEW_SCHEMA [#16, ProjectRecordBatch]
> Fragment 0:0
> {noformat}
> If the conversion is applied as UTF8 format, the same query succeeds:
> {noformat}
> 0: jdbc:drill:zk=local> select convert_from('{"abc":"xyz"}', 'utf8') as x
> from cp.`tpch/region.parquet` where r_regionkey = ;
> ++
> | x |
> ++
> ++
> No rows selected (0.241 seconds)
> {noformat}
> The reason for this is the special handling in the ProjectRecordBatch for
> JSON. The output schema is not known for this until the run time and the
> ComplexWriter in the Project relies on seeing the input data to determine the
> output schema - this could be a MapVector or ListVector etc.
> If the input data has 0 rows due to a filter condition, we should at least
> produce a default output schema, e.g an empty MapVector ? Need to decide a
> good default. Note that the CONVERT_FROM(x, 'json') could occur on 2
> branches of a UNION-ALL and if one input is empty while the other side is
> not, it may still cause incompatibility.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DRILL-4676) Foreman.moveToState can block forever if called by the foreman thread while the query is still being setup
[ https://issues.apache.org/jira/browse/DRILL-4676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Suresh Ollala updated DRILL-4676: - Reviewer: Chun Chang > Foreman.moveToState can block forever if called by the foreman thread while > the query is still being setup > -- > > Key: DRILL-4676 > URL: https://issues.apache.org/jira/browse/DRILL-4676 > Project: Apache Drill > Issue Type: Bug > Components: Execution - Flow >Affects Versions: 1.6.0 >Reporter: Deneche A. Hakim >Assignee: Deneche A. Hakim > Fix For: 1.7.0 > > > When the query is being setup, foreman has a special CountDownLatch that > blocks rpc threads from delivering external events, this latch is unblocked > at the end of the query setup. > In some cases though, when the foreman is submitting remote fragments, a > failure in RpcBus.send() causes an exception to be thrown that is reported to > Foreman.FragmentSubmitListener and blocks in the CountDownLatch. This causes > the foreman thread to block forever, and can rpc threads to be blocked too. > This seems to happen more frequently at a high concurrency load, and also can > prevent clients from connecting to the Drillbits. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-4654) Expose New System Metrics
[ https://issues.apache.org/jira/browse/DRILL-4654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Suresh Ollala updated DRILL-4654: - Reviewer: Krystal > Expose New System Metrics > - > > Key: DRILL-4654 > URL: https://issues.apache.org/jira/browse/DRILL-4654 > Project: Apache Drill > Issue Type: Improvement >Reporter: Sudheesh Katkam >Assignee: Sudheesh Katkam > Fix For: 1.8.0 > > > + Add more metrics to the DrillMetrics registry (exposed through web UI and > jconsole, through JMX): pending queries, running queries, completed queries, > current memory usage (root allocator) > + Clean up and document metric registration API > -+ Deprecate getMetrics() method in contextual objects; use > DrillMetrics.getRegistry() directly- > + Make JMX reporting and log reporting configurable through system properties > (since config file is not meant to be used in common module) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-4298) SYSTEM ERROR: ChannelClosedException
[
https://issues.apache.org/jira/browse/DRILL-4298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Suresh Ollala updated DRILL-4298:
-
Assignee: Deneche A. Hakim
Reviewer: Chun Chang
> SYSTEM ERROR: ChannelClosedException
>
>
> Key: DRILL-4298
> URL: https://issues.apache.org/jira/browse/DRILL-4298
> Project: Apache Drill
> Issue Type: Bug
> Components: Execution - RPC
>Affects Versions: 1.5.0
>Reporter: Chun Chang
>Assignee: Deneche A. Hakim
> Fix For: 1.7.0
>
>
> 1.5.0-SNAPSHOT2f0e3f27e630d5ac15cdaef808564e01708c3c55
> Running functional regression, hit this error, seems random and not
> associated with any particular query.
> From client side:
> {noformat}
> 1/5 create table `existing_partition_pruning/lineitempart` partition
> by (dir0) as select * from
> dfs.`/drill/testdata/partition_pruning/dfs/lineitempart`;
> [1;31mError: SYSTEM ERROR: ChannelClosedException: Channel closed
> /10.10.100.171:31010 <--> /10.10.100.171:33713.
> Fragment 0:0
> [Error Id: 772d90b8-c5e6-4ecc-8776-68ccc6b57d49 on drillats1.qa.lab:31010]
> (state=,code=0)[m
> java.sql.SQLException: SYSTEM ERROR: ChannelClosedException: Channel closed
> /10.10.100.171:31010 <--> /10.10.100.171:33713.
> Fragment 0:0
> [Error Id: 772d90b8-c5e6-4ecc-8776-68ccc6b57d49 on drillats1.qa.lab:31010]
> at
> org.apache.drill.jdbc.impl.DrillCursor.nextRowInternally(DrillCursor.java:247)
> at org.apache.drill.jdbc.impl.DrillCursor.next(DrillCursor.java:321)
> at
> net.hydromatic.avatica.AvaticaResultSet.next(AvaticaResultSet.java:187)
> at
> org.apache.drill.jdbc.impl.DrillResultSetImpl.next(DrillResultSetImpl.java:172)
> at sqlline.IncrementalRows.hasNext(IncrementalRows.java:62)
> at
> sqlline.TableOutputFormat$ResizingRowsProvider.next(TableOutputFormat.java:87)
> at sqlline.TableOutputFormat.print(TableOutputFormat.java:118)
> at sqlline.SqlLine.print(SqlLine.java:1593)
> at sqlline.Commands.execute(Commands.java:852)
> at sqlline.Commands.sql(Commands.java:751)
> at sqlline.SqlLine.dispatch(SqlLine.java:746)
> at sqlline.SqlLine.runCommands(SqlLine.java:1651)
> at sqlline.Commands.run(Commands.java:1304)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> sqlline.ReflectiveCommandHandler.execute(ReflectiveCommandHandler.java:36)
> at sqlline.SqlLine.dispatch(SqlLine.java:742)
> at sqlline.SqlLine.initArgs(SqlLine.java:553)
> at sqlline.SqlLine.begin(SqlLine.java:596)
> at sqlline.SqlLine.start(SqlLine.java:375)
> at sqlline.SqlLine.main(SqlLine.java:268)
> Caused by: org.apache.drill.common.exceptions.UserRemoteException: SYSTEM
> ERROR: ChannelClosedException: Channel closed /10.10.100.171:31010 <-->
> /10.10.100.171:33713.
> Fragment 0:0
> [Error Id: 772d90b8-c5e6-4ecc-8776-68ccc6b57d49 on drillats1.qa.lab:31010]
> at
> org.apache.drill.exec.rpc.user.QueryResultHandler.resultArrived(QueryResultHandler.java:119)
> at
> org.apache.drill.exec.rpc.user.UserClient.handleReponse(UserClient.java:113)
> at
> org.apache.drill.exec.rpc.BasicClientWithConnection.handle(BasicClientWithConnection.java:46)
> at
> org.apache.drill.exec.rpc.BasicClientWithConnection.handle(BasicClientWithConnection.java:31)
> at org.apache.drill.exec.rpc.RpcBus.handle(RpcBus.java:67)
> at org.apache.drill.exec.rpc.RpcBus$RequestEvent.run(RpcBus.java:374)
> at
> org.apache.drill.common.SerializedExecutor$RunnableProcessor.run(SerializedExecutor.java:89)
> at
> org.apache.drill.exec.rpc.RpcBus$SameExecutor.execute(RpcBus.java:252)
> at
> org.apache.drill.common.SerializedExecutor.execute(SerializedExecutor.java:123)
> at
> org.apache.drill.exec.rpc.RpcBus$InboundHandler.decode(RpcBus.java:285)
> at
> org.apache.drill.exec.rpc.RpcBus$InboundHandler.decode(RpcBus.java:257)
> at
> io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:89)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:339)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:324)
> at
> io.netty.handler.timeout.IdleStateHandler.channelRead(IdleStateHandler.java:254)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:339)
> at
>
[jira] [Updated] (DRILL-4479) JsonReader should pick a less restrictive type when creating the default column
[
https://issues.apache.org/jira/browse/DRILL-4479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Suresh Ollala updated DRILL-4479:
-
Reviewer: Chun Chang
> JsonReader should pick a less restrictive type when creating the default
> column
> ---
>
> Key: DRILL-4479
> URL: https://issues.apache.org/jira/browse/DRILL-4479
> Project: Apache Drill
> Issue Type: Bug
> Components: Storage - JSON
>Affects Versions: 1.5.0
>Reporter: Aman Sinha
>Assignee: Aman Sinha
> Fix For: 1.7.0
>
> Attachments: mostlynulls.json
>
>
> This JIRA is related to DRILL-3806 but has a narrower scope, so I decided to
> create separate one.
> The JsonReader has the method ensureAtLeastOneField() (see
> https://github.com/apache/drill/blob/master/exec/java-exec/src/main/java/org/apache/drill/exec/vector/complex/fn/JsonReader.java#L91)
> that ensures that when no columns are found, create an empty one and it
> chooses to create a nullable int column. One consequence is that queries of
> the following type fail:
> {noformat}
> select c1 from dfs.`mostlynulls.json`;
> ...
> ...
> | null |
> | null |
> Error: DATA_READ ERROR: Error parsing JSON - You tried to write a VarChar
> type when you are using a ValueWriter of type NullableIntWriterImpl.
> File /Users/asinha/data/mostlynulls.json
> Record 4097
> {noformat}
> In this file the first 4096 rows have NULL values for c1 followed by rows
> that have a valid string.
> It would be useful for the Json reader to choose a less restrictive type such
> as varchar in order to allow more types of queries to run.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DRILL-3826) Concurrent Query Submission leads to Channel Closed Exception
[
https://issues.apache.org/jira/browse/DRILL-3826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Suresh Ollala updated DRILL-3826:
-
Assignee: Deneche A. Hakim
Reviewer: Rahul Challapalli
> Concurrent Query Submission leads to Channel Closed Exception
> -
>
> Key: DRILL-3826
> URL: https://issues.apache.org/jira/browse/DRILL-3826
> Project: Apache Drill
> Issue Type: Bug
> Components: Client - JDBC, Execution - RPC
>Affects Versions: 1.1.0, 1.2.0
> Environment: - CentOS release 6.6 (Final)
> - hadoop-2.7.1
> - hbase-1.0.1.1
> - drill-1.1.0
> - jdk-1.8.0_45
>Reporter: Yiyi Hu
>Assignee: Deneche A. Hakim
> Labels: filesystem, hadoop, hbase, jdbc, rpc
> Fix For: 1.7.0
>
> Attachments: jdbc-test-client-drillbit.log, shell-sqlline.log,
> shell-test-drillbit.log
>
>
> Frequently seen CHANNEL CLOSED EXCEPTION while running concurrent quries with
> relatively large LIMIT.
> Here are the details,
> SET UP:
> - Single drillbit running on a single zookeeper node
> - 4G heap size, 8G direct memory
> - Storage plugins: local filesystem, hdfs, hbase
> TEST DATA:
> - A 50,000,000 records json file test.json, with two fields id,
> title (approximately 3G).
> SHELL TEST:
> - Running 4 drill shells concurrently with query:
> SELECT id, title from dfs.`test.json` LIMIT 500.
> - Queries got canceled. Channel closing between client and server were seen
> randomly, as an example shown below:
> {noformat}
> java.lang.RuntimeException: java.sql.SQLException: SYSTEM ERROR:
> ChannelClosedException: Channel closed /192.168.4.201:31010 <-->
> /192.168.4.201:48829.
> Fragment 0:0
> [Error Id: 0bd2b500-155e-46e0-9f26-bd89fea47a25 on TEST-101:31010]
> at sqlline.IncrementalRows.hasNext(IncrementalRows.java:73)
> at
> sqlline.TableOutputFormat$ResizingRowsProvider.next(TableOutputFormat.java:87)
> at sqlline.TableOutputFormat.print(TableOutputFormat.java:118)
> at sqlline.SqlLine.print(SqlLine.java:1583)
> at sqlline.Commands.execute(Commands.java:852)
> at sqlline.Commands.sql(Commands.java:751)
> at sqlline.SqlLine.dispatch(SqlLine.java:738)
> at sqlline.SqlLine.begin(SqlLine.java:612)
> at sqlline.SqlLine.start(SqlLine.java:366)
> at sqlline.SqlLine.main(SqlLine.java:259)
> {noformat}
> JDBC TEST:
> - 6 separate threads running the same query: SELECT id, title from
> dfs.`test.json` LIMIT 1000, each maintains its own connection. ResultSet,
> statement and connection are closed finally.
> - Throws the same channel closed exception randomly. Log file were enclosed
> for review.
> - Memory usage was monitored, all good.
> CROSS STORAGE PLUGINS:
> - The same issue can be found not only in JSON on a file system (local/hdfs),
> but also in HBASE.
> - The issue was not found in a single thread application.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DRILL-3833) Concurrent Queries Failed Unexpectedly
[
https://issues.apache.org/jira/browse/DRILL-3833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Suresh Ollala updated DRILL-3833:
-
Assignee: Deneche A. Hakim
Reviewer: Rahul Challapalli
> Concurrent Queries Failed Unexpectedly
> --
>
> Key: DRILL-3833
> URL: https://issues.apache.org/jira/browse/DRILL-3833
> Project: Apache Drill
> Issue Type: Bug
> Components: Client - JDBC, Execution - RPC
>Affects Versions: 1.1.0, 1.2.0
> Environment: CentOS release 6.6 (Final)
> Hadoop-2.7.1
> Drill-1.1.0
> Single drillbit on single zookeeper
>Reporter: Yiyi Hu
>Assignee: Deneche A. Hakim
> Labels: hdfs, jdbc, rpc
> Fix For: 1.7.0
>
> Attachments: drillbit.log
>
>
> Concurrent queries with a relatively large LIMIT size *failed*, where the
> failure occurred randomly.
> To reproduce:
> - Test data: a JSON file test.json (at least 10,000,000 records, two fields
> id, title);
> - Submit 5 queries with 5 separate threads using jdbc, where the query is:
> {panel}
> SELECT id, title FROM dfs.`test.json` LIMIT 1000;
> {panel}
> - The error message in drillbit.log:
> {noformat}
> 2015-09-24 19:15:15,393 [Client-1] INFO
> o.a.d.j.i.DrillResultSetImpl$ResultsListener - [#4] Query failed:
> org.apache.drill.common.exceptions.UserRemoteException: SYSTEM ERROR:
> ChannelClosedException: Channel closed /192.168.4.201:31010 <-->
> /192.168.4.201:58795.
> Fragment 0:0
> [Error Id: 60a7baa8-a2ed-47e6-b7ca-68afd82c852a on TEST-101:31010]
> at
> org.apache.drill.exec.rpc.user.QueryResultHandler.resultArrived(QueryResultHandler.java:118)
> [drill-java-exec-1.1.0.jar:1.1.0]
> at
> org.apache.drill.exec.rpc.user.UserClient.handleReponse(UserClient.java:111)
> [drill-java-exec-1.1.0.jar:1.1.0]
> at
> org.apache.drill.exec.rpc.BasicClientWithConnection.handle(BasicClientWithConnection.java:47)
> [drill-java-exec-1.1.0.jar:1.1.0]
> at
> org.apache.drill.exec.rpc.BasicClientWithConnection.handle(BasicClientWithConnection.java:32)
> [drill-java-exec-1.1.0.jar:1.1.0]
> at org.apache.drill.exec.rpc.RpcBus.handle(RpcBus.java:61)
> [drill-java-exec-1.1.0.jar:1.1.0]
> at
> org.apache.drill.exec.rpc.RpcBus$InboundHandler.decode(RpcBus.java:233)
> [drill-java-exec-1.1.0.jar:1.1.0]
> at
> org.apache.drill.exec.rpc.RpcBus$InboundHandler.decode(RpcBus.java:205)
> [drill-java-exec-1.1.0.jar:1.1.0]
> at
> io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:89)
> [netty-codec-4.0.27.Final.jar:4.0.27.Final]
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:339)
> [netty-transport-4.0.27.Final.jar:4.0.27.Final]
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:324)
> [netty-transport-4.0.27.Final.jar:4.0.27.Final]
> at
> io.netty.handler.timeout.IdleStateHandler.channelRead(IdleStateHandler.java:254)
> [netty-handler-4.0.27.Final.jar:4.0.27.Final]
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:339)
> [netty-transport-4.0.27.Final.jar:4.0.27.Final]
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:324)
> [netty-transport-4.0.27.Final.jar:4.0.27.Final]
> at
> io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:103)
> [netty-codec-4.0.27.Final.jar:4.0.27.Final]
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:339)
> [netty-transport-4.0.27.Final.jar:4.0.27.Final]
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:324)
> [netty-transport-4.0.27.Final.jar:4.0.27.Final]
> at
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:242)
> [netty-codec-4.0.27.Final.jar:4.0.27.Final]
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:339)
> [netty-transport-4.0.27.Final.jar:4.0.27.Final]
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:324)
> [netty-transport-4.0.27.Final.jar:4.0.27.Final]
> at
> io.netty.channel.ChannelInboundHandlerAdapter.channelRead(ChannelInboundHandlerAdapter.java:86)
> [netty-transport-4.0.27.Final.jar:4.0.27.Final]
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:339)
> [netty-transport-4.0.27.Final.jar:4.0.27.Final]
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:324)
>
[jira] [Commented] (DRILL-4618) random numbers generator function broken
[
https://issues.apache.org/jira/browse/DRILL-4618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15304412#comment-15304412
]
ASF GitHub Bot commented on DRILL-4618:
---
Github user StevenMPhillips commented on a diff in the pull request:
https://github.com/apache/drill/pull/509#discussion_r64940411
--- Diff:
exec/java-exec/src/main/java/org/apache/drill/exec/expr/EvaluationVisitor.java
---
@@ -811,7 +811,7 @@ public HoldingContainer visitFunctionCall(FunctionCall
call, ClassGenerator g
@Override
public HoldingContainer
visitFunctionHolderExpression(FunctionHolderExpression holder,
ClassGenerator generator) throws RuntimeException {
HoldingContainer hc = getPrevious(holder, generator.getMappingSet());
- if (hc == null) {
+ if (hc == null || holder.isRandom()) {
--- End diff --
I think this change is not sufficient to cover all cases. If random() is
just part of the expression, then this won't help. For example, the expression
2 * random().
I think a better way to fix this would be to modify
EqualityVisitor.visitFunctionHolderExpression() to return false if the function
is random. That way any expression which contains a random function will never
be considered equal to another expression.
> random numbers generator function broken
>
>
> Key: DRILL-4618
> URL: https://issues.apache.org/jira/browse/DRILL-4618
> Project: Apache Drill
> Issue Type: Bug
>Reporter: Chunhui Shi
>Assignee: Chunhui Shi
>
> File this JIRA based on the the bug description from Ted's email and
> discussion in dev mail list for record purpose:
> I am trying to generate some random numbers. I have a large base file (foo)
> this is what I get:
> 0: jdbc:drill:> select floor(1000*random()) as x, floor(1000*random()) as
> y, floor(1000*rand()) as z from (select * from maprfs.tdunning.foo) a limit
> 20;
> ++++
> | x| y| z|
> ++++
> | 556.0 | 556.0 | 618.0 |
> | 564.0 | 564.0 | 618.0 |
> | 129.0 | 129.0 | 618.0 |
> | 48.0 | 48.0 | 618.0 |
> | 696.0 | 696.0 | 618.0 |
> | 642.0 | 642.0 | 618.0 |
> | 535.0 | 535.0 | 618.0 |
> | 440.0 | 440.0 | 618.0 |
> | 894.0 | 894.0 | 618.0 |
> | 24.0 | 24.0 | 618.0 |
> | 508.0 | 508.0 | 618.0 |
> | 28.0 | 28.0 | 618.0 |
> | 816.0 | 816.0 | 618.0 |
> | 717.0 | 717.0 | 618.0 |
> | 334.0 | 334.0 | 618.0 |
> | 978.0 | 978.0 | 618.0 |
> | 646.0 | 646.0 | 618.0 |
> | 787.0 | 787.0 | 618.0 |
> | 260.0 | 260.0 | 618.0 |
> | 711.0 | 711.0 | 618.0 |
> ++++
> On this page, https://drill.apache.org/docs/math-and-trig/, the rand
> function is described and random() is not. But it appears that rand()
> delivers a constant instead (although a different constant each time the
> query is run) and it appears that random() delivers the same value when
> used multiple times in each returned value.
> This seems very, very wrong.
> The fault does not seem to be related to my querying a table:
> 0: jdbc:drill:> select rand(), random(), random() from (values (1),(2),(3))
> x;
> +-+---+---+
> | EXPR$0|EXPR$1 |EXPR$2 |
> +-+---+---+
> | 0.1347749257216052 | 0.36724556209765014 | 0.36724556209765014 |
> | 0.1347749257216052 | 0.006087161689924625 | 0.006087161689924625 |
> | 0.1347749257216052 | 0.09417099142512142 | 0.09417099142512142 |
> +-+---+---+
> For reference, postgres doesn't have rand() and does the right thing with
> random().
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (DRILL-4698) Cant read parquet partitioning from Azure Blob Storage
Roberto Grandi created DRILL-4698: - Summary: Cant read parquet partitioning from Azure Blob Storage Key: DRILL-4698 URL: https://issues.apache.org/jira/browse/DRILL-4698 Project: Apache Drill Issue Type: Bug Components: Storage - Parquet Affects Versions: 1.6.0 Environment: Windows Reporter: Roberto Grandi Priority: Minor I have created a partitioned parquet file with Azure Hd Insight. When reading this parquet file Drill seems not to be able to read partitions, for instance /root /site=site1 /datekey=20160501 /parquet file 1.parquet When running: SELECT site, datekey, other fileds FROM azure.root i obtain NULL NULL, other fields. Can you help me fix this issue? Thanks Roberto -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DRILL-4690) Header in RestApi CORS support
[ https://issues.apache.org/jira/browse/DRILL-4690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15303650#comment-15303650 ] ASF GitHub Bot commented on DRILL-4690: --- Github user PythonicNinja commented on the pull request: https://github.com/apache/drill/pull/507#issuecomment-222073117 I have updated PR according to your and laurentgo ideas. @hnfgns: Can you check second round of review? > Header in RestApi CORS support > --- > > Key: DRILL-4690 > URL: https://issues.apache.org/jira/browse/DRILL-4690 > Project: Apache Drill > Issue Type: Improvement >Reporter: Wojciech Nowak >Priority: Minor > > Damien Cantreras raised question on mailing list, related to Drill RestAPI > support for Header "Access-Control-Allow-Origin: *" > to allow it being used from a HTML5 application. > Place where Header should be added > https://github.com/apache/drill/blob/master/exec/java-exec/src/main/java/org/apache/drill/exec/server/rest/WebServer.java > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
