Hi Sudheesh, There is another related issue around this.
For the same data I've used for DRILL-4890 <https://issues.apache.org/jira/browse/DRILL-4890>, below query doesn't return any result (which is supposed to return one row) select city[0] as cityalias from dfs.tmp.`data.json` a join (select id as idalias from dfs.tmp.`cities.json`) b on a.*cityalias *= b.idalias However, the query below works fine select city[0] as cityalias from dfs.tmp.`data.json` a join (select id as idalias from dfs.tmp.`cities.json`) b on a.*city[0] * = b.idalias Using an alias for city[0] in the join condition makes it return no result. Any idea, is this a known issue (is there any JIRA issue already tracked for this) or should a separate JIRA issue be filed for this? *Files used for testing:* *Json file 1: data.json* { "name": "Jim","city" : [1,2]} *Json file 2: cities.json* {id:1,name:"Sendurai"} {id:2,name:"NYC"} Thanks, Kathir On Wed, Sep 14, 2016 at 8:23 AM, Kathiresan S <[email protected]> wrote: > Hi Sudheesh, > > I've filed a JIRA for this > > https://issues.apache.org/jira/browse/DRILL-4890 > > Thanks, > Kathir > > On Wed, Sep 14, 2016 at 8:09 AM, Kathiresan S < > [email protected]> wrote: > >> Hi Sudheesh, >> >> Thanks for checking this out. >> I do get the same error what you get, when i run Drillbit on my Eclipse >> and run the same query from WebUI pointing to my local instance, and on top >> of this error, i do get the "QueryDataBatch was released twice" error as >> well. >> >> But, in drillbit.log of one of the nodes on the cluster, where this >> failed, i don't see the IndexOutOfBoundsException. Somehow, the >> IndexOutOfBoundsException >> log is getting suppressed and only the QueryDataBatch error is logged. But >> thats a separate issue. >> >> I did run it from WebUI and its in RUNNING state forever (actually i >> started one yesterday and left the tab, its still in RUNNING state) >> >> Sure, I'll file a JIRA and will provide the details here. >> >> Thanks again! >> >> Regards, >> Kathir >> >> >> On Tue, Sep 13, 2016 at 8:17 PM, Sudheesh Katkam <[email protected]> >> wrote: >> >>> Hi Kathir, >>> >>> I tried the same query in embedded mode, and I got a different error. >>> >>> java.lang.IndexOutOfBoundsException: index: 0, length: 8 (expected: >>> range(0, 0)) >>> at io.netty.buffer.DrillBuf.checkIndexD(DrillBuf.java:123) >>> at io.netty.buffer.DrillBuf.chk(DrillBuf.java:147) >>> at io.netty.buffer.DrillBuf.getLong(DrillBuf.java:493) >>> at org.apache.drill.exec.vector.BigIntVector$Accessor.get(BigIn >>> tVector.java:353) >>> at org.apache.drill.exec.vector.BigIntVector$Accessor.getObject >>> (BigIntVector.java:359) >>> at org.apache.drill.exec.vector.RepeatedBigIntVector$Accessor.g >>> etObject(RepeatedBigIntVector.java:297) >>> at org.apache.drill.exec.vector.RepeatedBigIntVector$Accessor.g >>> etObject(RepeatedBigIntVector.java:288) >>> at org.apache.drill.exec.vector.accessor.GenericAccessor.getObj >>> ect(GenericAccessor.java:44) >>> at org.apache.drill.exec.vector.accessor.BoundCheckingAccessor. >>> getObject(BoundCheckingAccessor.java:148) >>> at org.apache.drill.jdbc.impl.TypeConvertingSqlAccessor.getObje >>> ct(TypeConvertingSqlAccessor.java:795) >>> at org.apache.drill.jdbc.impl.AvaticaDrillSqlAccessor.getObject >>> (AvaticaDrillSqlAccessor.java:179) >>> ... >>> >>> In this case, the Java client library is not able to consume the results >>> sent from the server, and the query was CANCELLED (as seen in the query >>> profile, on the web UI). Are you seeing the same? >>> >>> I am not aware of any workarounds; this seems like a bug to me. Can you >>> open a ticket <https://issues.apache.org/jira/browse/DRILL>? >>> >>> Thank you, >>> Sudheesh >>> >>> > On Sep 13, 2016, at 7:10 AM, Kathiresan S < >>> [email protected]> wrote: >>> > >>> > Hi, >>> > >>> > Additional info on this. Array column ('city' in the example) is the >>> issue. >>> > >>> > 1. When i select the just the first occurrence of the array column, the >>> > query works fine >>> > >>> > select a.name,a.city[0],b.name from dfs.tmp.`data.json` a right join >>> > dfs.tmp.`cities.json` b on a.city[0]=b.id >>> > >>> > Result >>> > Jim 1 Sendurai >>> > null null NYC >>> > >>> > >>> > 2. And when i do a repeated_count on the array column, it returns -2 >>> on the >>> > second row >>> > >>> > select a.name,repeated_count(a.city),b.name from dfs.tmp.`data.json` a >>> > right join dfs.tmp.`cities.json` b on a.city[0]=b.id >>> > >>> > Result >>> > Jim 2 Sendurai >>> > null -2 NYC >>> > >>> > Any idea/work around for this issue would be highly appreciated >>> > >>> > Thanks, >>> > Kathir >>> > >>> > >>> > On Sat, Sep 10, 2016 at 9:56 PM, Kathiresan S < >>> [email protected]> >>> > wrote: >>> > >>> >> Hi, A Query with right outer join fails while the inner and left >>> outer >>> >> joins work for the same data. I've replicated the issue with some >>> simple >>> >> data here and this happens in both 1.6.0 and 1.8.0 >>> >> >>> >> *Json file 1: data.json* >>> >> >>> >> { "name": "Jim","city" : [1,2]} >>> >> >>> >> *Json file 2: cities.json* >>> >> >>> >> {id:1,name:"Sendurai"} >>> >> {id:2,name:"NYC"} >>> >> >>> >> *Queries that work:* >>> >> 1. select a.name,a.city,b.id,b.name from dfs.tmp.`data.json` a left >>> >> outer join dfs.tmp.`cities.json` b on a.city[0]=b.id >>> >> >>> >> 2. select a.name,a.city,b.id,b.name from dfs.tmp.`data.json` a join >>> >> dfs.tmp.`cities.json` b on a.city[0]=b.id >>> >> >>> >> *Query that fails:* >>> >> >>> >> select a.name,a.city,b.id,b.name from dfs.tmp.`data.json` a right >>> outer >>> >> join dfs.tmp.`cities.json` b on a.city[0]=b.id >>> >> >>> >> *On the server side, i see below error trace :* >>> >> >>> >> java.lang.IllegalStateException: QueryDataBatch was released twice. >>> >> at org.apache.drill.exec.rpc.user >>> .QueryDataBatch.release(QueryDataBatch.java:56) >>> >> [drill-java-exec-1.6.0.jar:1.6.0] >>> >> at org.apache.drill.exec.rpc.user >>> .QueryResultHandler.batchArrived(QueryResultHandler.java:167) >>> >> [drill-java-exec-1.6.0.jar:1.6.0] >>> >> at org.apache.drill.exec.rpc.user >>> .UserClient.handleReponse(UserClient.java:110) >>> >> ~[drill-java-exec-1.6.0.jar:1.6.0] >>> >> at org.apache.drill.exec.rpc.BasicClientWithConnection.handle( >>> >> BasicClientWithConnection.java:46) ~[drill-rpc-1.6.0.jar:1.6.0] >>> >> at org.apache.drill.exec.rpc.BasicClientWithConnection.handle( >>> >> BasicClientWithConnection.java:31) ~[drill-rpc-1.6.0.jar:1.6.0] >>> >> at org.apache.drill.exec.rpc.RpcBus.handle(RpcBus.java:67) >>> >> ~[drill-rpc-1.6.0.jar:1.6.0] >>> >> at org.apache.drill.exec.rpc.RpcB >>> us$RequestEvent.run(RpcBus.java:374) >>> >> ~[drill-rpc-1.6.0.jar:1.6.0] >>> >> at org.apache.drill.common.SerializedExecutor$ >>> >> RunnableProcessor.run(SerializedExecutor.java:89) >>> >> [drill-rpc-1.6.0.jar:1.6.0] >>> >> at org.apache.drill.exec.rpc.RpcB >>> us$SameExecutor.execute(RpcBus.java:252) >>> >> [drill-rpc-1.6.0.jar:1.6.0] >>> >> at org.apache.drill.common.Serial >>> izedExecutor.execute(SerializedExecutor.java:123) >>> >> [drill-rpc-1.6.0.jar:1.6.0] >>> >> at org.apache.drill.exec.rpc.RpcB >>> us$InboundHandler.decode(RpcBus.java:285) >>> >> [drill-rpc-1.6.0.jar:1.6.0] >>> >> at org.apache.drill.exec.rpc.RpcB >>> us$InboundHandler.decode(RpcBus.java:257) >>> >> [drill-rpc-1.6.0.jar:1.6.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.AbstractChann >>> elHandlerContext.fireChannelRead( >>> >> AbstractChannelHandlerContext.java:324) >>> [netty-transport-4.0.27.Final. >>> >> jar:4.0.27.Final] >>> >> at io.netty.handler.timeout.IdleS >>> tateHandler.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.AbstractChann >>> elHandlerContext.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.AbstractChann >>> elHandlerContext.fireChannelRead( >>> >> AbstractChannelHandlerContext.java:324) >>> [netty-transport-4.0.27.Final. >>> >> jar:4.0.27.Final] >>> >> at io.netty.handler.codec.ByteToM >>> essageDecoder.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.AbstractChann >>> elHandlerContext.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.AbstractChann >>> elHandlerContext.fireChannelRead( >>> >> AbstractChannelHandlerContext.java:324) >>> [netty-transport-4.0.27.Final. >>> >> jar:4.0.27.Final] >>> >> at io.netty.channel.DefaultChannelPipeline.fireChannelRead( >>> >> DefaultChannelPipeline.java:847) [netty-transport-4.0.27.Final. >>> >> jar:4.0.27.Final] >>> >> >>> >> Thanks, >>> >> Kathir >>> >> >>> >>> >> >
