[
https://issues.apache.org/jira/browse/DRILL-3854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15005714#comment-15005714
]
Jacques Nadeau commented on DRILL-3854:
---------------------------------------
Posting my updated comment here as well since GitHub doesn't post comment
changes:
Let me expound.
There are three main modes for scalar replacement:
on: if scalar replacement fails, the query fails.
try: if scalar replacement fails, log a warning and continue executing the query
off: don't attempt scalar replacement.
We have Drill setup so that tests execute in "on" mode. This means if scalar
replacement fails, the test fails. We do this to ensure that we don't
accidentally break the scalar replacement functionality.
There are a small number of situations where scalar replacement functionality
doesn't work (certain expression patterns). For those tests, (and only those
tests), we set scalar replacement to "try" manually as part of those tests.
This means these tests pass and we get a silent warning stating scalar
replacement failed.
I think there must be more dynamics on this bug. In your example here, you
aren't actually changing the production behavior at all. The only change you
made was to how we run tests. The change you made means that the tests are
running the same as what people would expect in production. If your test above
passes with "try" and you don't get an exception, that means that everything is
working as it should be (e.g. no bug). However, Khurram is claiming that the
query fails in production (try) mode. It sounds like you should work with him
to understand whether his setup. It may be that it is accidentally in "on"
instead of "try". If he is in "try" mode, then your test is not reproducing the
problem. Otherwise, this patch would fail to execute.
> IOB Exception : CONVERT_FROM (sal, int_be)
> ------------------------------------------
>
> Key: DRILL-3854
> URL: https://issues.apache.org/jira/browse/DRILL-3854
> Project: Apache Drill
> Issue Type: Bug
> Components: Execution - Flow
> Affects Versions: 1.2.0
> Environment: 4 node cluster CentOS
> Reporter: Khurram Faraaz
> Assignee: Sean Hsuan-Yi Chu
> Priority: Critical
> Fix For: 1.4.0
>
> Attachments: log, run_time_code.txt
>
>
> CONVERT_FROM function results in IOB Exception
> Drill master commit id : b9afcf8f
> {code}
> 0: jdbc:drill:schema=dfs.tmp> select salary from Emp;
> +---------+
> | salary |
> +---------+
> | 80000 |
> | 90000 |
> | 200000 |
> | 95000 |
> | 85000 |
> | 90000 |
> | 100000 |
> | 87000 |
> | 80000 |
> | 100000 |
> | 99000 |
> +---------+
> 11 rows selected (0.535 seconds)
> # create table using above Emp table
> create table tbl_int_be as select convert_to(salary, 'int_be') sal from Emp;
> 0: jdbc:drill:schema=dfs.tmp> alter session set `planner.slice_target`=1;
> +-------+--------------------------------+
> | ok | summary |
> +-------+--------------------------------+
> | true | planner.slice_target updated. |
> +-------+--------------------------------+
> 1 row selected (0.19 seconds)
> # Below query results in IOB on server.
> 0: jdbc:drill:schema=dfs.tmp> select convert_from(sal, 'int_be') from
> tbl_int_be order by sal;
> Error: SYSTEM ERROR: IndexOutOfBoundsException: DrillBuf(ridx: 0, widx: 158,
> cap: 158/158, unwrapped: SlicedByteBuf(ridx: 0, widx: 158, cap: 158/158,
> unwrapped: UnsafeDirectLittleEndian(PooledUnsafeDirectByteBuf(ridx: 0, widx:
> 0, cap: 417/417)))).slice(158, 44)
> Fragment 2:0
> [Error Id: 4ee1361d-9877-45eb-bde6-57d5add9fe5e on centos-04.qa.lab:31010]
> (state=,code=0)
> # Apply convert_from function and project original column results in IOB on
> client. (because Error Id is missing)
> 0: jdbc:drill:schema=dfs.tmp> select convert_from(sal, 'int_be'), sal from
> tbl_int_be;
> Error: Unexpected RuntimeException: java.lang.IndexOutOfBoundsException:
> DrillBuf(ridx: 0, widx: 114, cap: 114/114, unwrapped: DrillBuf(ridx: 321,
> widx: 321, cap: 321/321, unwrapped:
> UnsafeDirectLittleEndian(PooledUnsafeDirectByteBuf(ridx: 0, widx: 0, cap:
> 321/321)))).slice(55, 103) (state=,code=0)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
