[jira] [Created] (DRILL-4677) Cast to TIMESTAMP within value constructor results in IllegalArgumentException
Khurram Faraaz created DRILL-4677:
-
Summary: Cast to TIMESTAMP within value constructor results in
IllegalArgumentException
Key: DRILL-4677
URL: https://issues.apache.org/jira/browse/DRILL-4677
Project: Apache Drill
Issue Type: Bug
Components: Execution - Data Types
Affects Versions: 1.7.0
Environment: 4 node cluster CentOS
Reporter: Khurram Faraaz
Cast string to TIMESTAMP inside value constructor results in
IllegalArgumentException
Drill version : 1.7.0-SNAPSHOT, commit ID : 09b26277
{noformat}
0: jdbc:drill:schema=dfs.tmp> SELECT tmstmp FROM (
. . . . . . . . . . . . . . > VALUES(cast('2015-04-22 11:35:17.387006' as
TIMESTAMP)))
. . . . . . . . . . . . . . > tbl(tmstmp);
Error: SYSTEM ERROR: IllegalArgumentException: Invalid format: "2015-04-22
11:35:17.387006" is malformed at "006"
Fragment 0:0
[Error Id: e793c5e5-8abc-4a4a-9951-a5c9069d600c on centos-01.qa.lab:31010]
(state=,code=0)
{noformat}
When used with out CAST to TIMESTAMP, Drill returns correct results.
{noformat}
0: jdbc:drill:schema=dfs.tmp> SELECT tmstmp FROM (
. . . . . . . . . . . . . . > VALUES('2015-04-22 11:35:17.387006'))
. . . . . . . . . . . . . . > tbl(tmstmp);
+-+
| tmstmp|
+-+
| 2015-04-22 11:35:17.387006 |
+-+
1 row selected (0.547 seconds)
{noformat}
Results from postgres for above query, note that there is a cast to timestamp
used in query.
{noformat}
postgres=# SELECT tmstmp FROM (VALUES(cast('2015-04-22 11:35:17.387006' as
TIMESTAMP))) tbl(tmstmp);
tmstmp
2015-04-22 11:35:17.387006
(1 row)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (DRILL-4678) Query HANG - SELECT DISTINCT over date data
Khurram Faraaz created DRILL-4678:
-
Summary: Query HANG - SELECT DISTINCT over date data
Key: DRILL-4678
URL: https://issues.apache.org/jira/browse/DRILL-4678
Project: Apache Drill
Issue Type: Bug
Components: Execution - Relational Operators
Affects Versions: 1.7.0
Environment: 4 node cluster CentOS
Reporter: Khurram Faraaz
Below query hangs
{noformat}
2016-05-16 10:33:57,506 [28c65de9-9f67-dadb-5e4e-e1a12f8dda49:foreman] INFO
o.a.drill.exec.work.foreman.Foreman - Query text for query id
28c65de9-9f67-dadb-5e4e-e1a12f8dda49: SELECT DISTINCT dt FROM (
VALUES(CAST('1964-03-07' AS DATE)),
(CAST('2002-03-04' AS DATE)),
(CAST('1966-09-04' AS DATE)),
(CAST('1993-08-18' AS DATE)),
(CAST('1970-06-11' AS DATE)),
(CAST('1970-06-11' AS DATE)),
(CAST('1970-06-11' AS DATE)),
(CAST('1970-06-11' AS DATE)),
(CAST('1970-06-11' AS DATE)),
(CAST('1959-10-23' AS DATE)),
(CAST('1992-01-14' AS DATE)),
(CAST('1994-07-24' AS DATE)),
(CAST('1979-11-25' AS DATE)),
(CAST('1945-01-14' AS DATE)),
(CAST('1982-07-25' AS DATE)),
(CAST('1966-09-06' AS DATE)),
(CAST('1989-05-01' AS DATE)),
(CAST('1996-03-08' AS DATE)),
(CAST('1998-08-19' AS DATE)),
(CAST('2013-08-13' AS DATE)),
(CAST('2013-08-13' AS DATE)),
(CAST('2013-08-13' AS DATE)),
(CAST('2013-08-13' AS DATE)),
(CAST('2013-08-13' AS DATE)),
(CAST('2013-08-13' AS DATE)),
(CAST('1999-07-20' AS DATE)),
(CAST('1962-07-03' AS DATE)),
(CAST('2011-08-17' AS DATE)),
(CAST('2011-05-16' AS DATE)),
(CAST('1946-05-08' AS DATE)),
(CAST('1994-02-13' AS DATE)),
(CAST('1978-08-09' AS DATE)),
(CAST('1978-08-09' AS DATE)),
(CAST('1978-08-09' AS DATE)),
(CAST('1978-08-09' AS DATE)),
(CAST('1958-02-06' AS DATE)),
(CAST('2012-06-11' AS DATE)),
(CAST('2012-06-11' AS DATE)),
(CAST('2012-06-11' AS DATE)),
(CAST('2012-06-11' AS DATE)),
(CAST('1998-03-26' AS DATE)),
(CAST('1996-11-04' AS DATE)),
(CAST('1953-09-25' AS DATE)),
(CAST('2003-06-17' AS DATE)),
(CAST('2003-06-17' AS DATE)),
(CAST('2003-06-17' AS DATE)),
(CAST('2003-06-17' AS DATE)),
(CAST('2003-06-17' AS DATE)),
(CAST('1980-07-05' AS DATE)),
(CAST('1982-06-15' AS DATE)),
(CAST('1951-05-16' AS DATE)))
tbl(dt)
{noformat}
Details from Web UI Profile tab, please note that the query is still in
STARTING state
{noformat}
Running Queries
TimeUserQuery State Foreman
05/16/2016 10:33:57
mapr
SELECT DISTINCT dt FROM ( VALUES(CAST('1964-03-07' AS DATE)),
(CAST('2002-03-04' AS DATE)), (CAST('1966-09-04' AS DATE)), (CAST('199
STARTING
centos-01.qa.lab
{noformat}
There is no other useful information in drillbit.log. jstack output is attached
here for your reference.
The same query works fine on Postgres 9.3
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DRILL-4678) Query HANG - SELECT DISTINCT over date data
[
https://issues.apache.org/jira/browse/DRILL-4678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Khurram Faraaz updated DRILL-4678:
--
Priority: Critical (was: Major)
> Query HANG - SELECT DISTINCT over date data
> ---
>
> Key: DRILL-4678
> URL: https://issues.apache.org/jira/browse/DRILL-4678
> Project: Apache Drill
> Issue Type: Bug
> Components: Execution - Relational Operators
>Affects Versions: 1.7.0
> Environment: 4 node cluster CentOS
>Reporter: Khurram Faraaz
>Priority: Critical
> Attachments: hung_Date_Query.log
>
>
> Below query hangs
> {noformat}
> 2016-05-16 10:33:57,506 [28c65de9-9f67-dadb-5e4e-e1a12f8dda49:foreman] INFO
> o.a.drill.exec.work.foreman.Foreman - Query text for query id
> 28c65de9-9f67-dadb-5e4e-e1a12f8dda49: SELECT DISTINCT dt FROM (
> VALUES(CAST('1964-03-07' AS DATE)),
> (CAST('2002-03-04' AS DATE)),
> (CAST('1966-09-04' AS DATE)),
> (CAST('1993-08-18' AS DATE)),
> (CAST('1970-06-11' AS DATE)),
> (CAST('1970-06-11' AS DATE)),
> (CAST('1970-06-11' AS DATE)),
> (CAST('1970-06-11' AS DATE)),
> (CAST('1970-06-11' AS DATE)),
> (CAST('1959-10-23' AS DATE)),
> (CAST('1992-01-14' AS DATE)),
> (CAST('1994-07-24' AS DATE)),
> (CAST('1979-11-25' AS DATE)),
> (CAST('1945-01-14' AS DATE)),
> (CAST('1982-07-25' AS DATE)),
> (CAST('1966-09-06' AS DATE)),
> (CAST('1989-05-01' AS DATE)),
> (CAST('1996-03-08' AS DATE)),
> (CAST('1998-08-19' AS DATE)),
> (CAST('2013-08-13' AS DATE)),
> (CAST('2013-08-13' AS DATE)),
> (CAST('2013-08-13' AS DATE)),
> (CAST('2013-08-13' AS DATE)),
> (CAST('2013-08-13' AS DATE)),
> (CAST('2013-08-13' AS DATE)),
> (CAST('1999-07-20' AS DATE)),
> (CAST('1962-07-03' AS DATE)),
> (CAST('2011-08-17' AS DATE)),
> (CAST('2011-05-16' AS DATE)),
> (CAST('1946-05-08' AS DATE)),
> (CAST('1994-02-13' AS DATE)),
> (CAST('1978-08-09' AS DATE)),
> (CAST('1978-08-09' AS DATE)),
> (CAST('1978-08-09' AS DATE)),
> (CAST('1978-08-09' AS DATE)),
> (CAST('1958-02-06' AS DATE)),
> (CAST('2012-06-11' AS DATE)),
> (CAST('2012-06-11' AS DATE)),
> (CAST('2012-06-11' AS DATE)),
> (CAST('2012-06-11' AS DATE)),
> (CAST('1998-03-26' AS DATE)),
> (CAST('1996-11-04' AS DATE)),
> (CAST('1953-09-25' AS DATE)),
> (CAST('2003-06-17' AS DATE)),
> (CAST('2003-06-17' AS DATE)),
> (CAST('2003-06-17' AS DATE)),
> (CAST('2003-06-17' AS DATE)),
> (CAST('2003-06-17' AS DATE)),
> (CAST('1980-07-05' AS DATE)),
> (CAST('1982-06-15' AS DATE)),
> (CAST('1951-05-16' AS DATE)))
> tbl(dt)
> {noformat}
> Details from Web UI Profile tab, please note that the query is still in
> STARTING state
> {noformat}
> Running Queries
> Time UserQuery State Foreman
> 05/16/2016 10:33:57
> mapr
> SELECT DISTINCT dt FROM ( VALUES(CAST('1964-03-07' AS DATE)),
> (CAST('2002-03-04' AS DATE)), (CAST('1966-09-04' AS DATE)), (CAST('199
> STARTING
> centos-01.qa.lab
> {noformat}
> There is no other useful information in drillbit.log. jstack output is
> attached here for your reference.
> The same query works fine on Postgres 9.3
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DRILL-4678) Query HANG - SELECT DISTINCT over date data
[
https://issues.apache.org/jira/browse/DRILL-4678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Khurram Faraaz updated DRILL-4678:
--
Attachment: hung_Date_Query.log
jstack output is attached
Drill version : 1.7.0-SNAPSHOT, commit ID : 09b26277
> Query HANG - SELECT DISTINCT over date data
> ---
>
> Key: DRILL-4678
> URL: https://issues.apache.org/jira/browse/DRILL-4678
> Project: Apache Drill
> Issue Type: Bug
> Components: Execution - Relational Operators
>Affects Versions: 1.7.0
> Environment: 4 node cluster CentOS
>Reporter: Khurram Faraaz
> Attachments: hung_Date_Query.log
>
>
> Below query hangs
> {noformat}
> 2016-05-16 10:33:57,506 [28c65de9-9f67-dadb-5e4e-e1a12f8dda49:foreman] INFO
> o.a.drill.exec.work.foreman.Foreman - Query text for query id
> 28c65de9-9f67-dadb-5e4e-e1a12f8dda49: SELECT DISTINCT dt FROM (
> VALUES(CAST('1964-03-07' AS DATE)),
> (CAST('2002-03-04' AS DATE)),
> (CAST('1966-09-04' AS DATE)),
> (CAST('1993-08-18' AS DATE)),
> (CAST('1970-06-11' AS DATE)),
> (CAST('1970-06-11' AS DATE)),
> (CAST('1970-06-11' AS DATE)),
> (CAST('1970-06-11' AS DATE)),
> (CAST('1970-06-11' AS DATE)),
> (CAST('1959-10-23' AS DATE)),
> (CAST('1992-01-14' AS DATE)),
> (CAST('1994-07-24' AS DATE)),
> (CAST('1979-11-25' AS DATE)),
> (CAST('1945-01-14' AS DATE)),
> (CAST('1982-07-25' AS DATE)),
> (CAST('1966-09-06' AS DATE)),
> (CAST('1989-05-01' AS DATE)),
> (CAST('1996-03-08' AS DATE)),
> (CAST('1998-08-19' AS DATE)),
> (CAST('2013-08-13' AS DATE)),
> (CAST('2013-08-13' AS DATE)),
> (CAST('2013-08-13' AS DATE)),
> (CAST('2013-08-13' AS DATE)),
> (CAST('2013-08-13' AS DATE)),
> (CAST('2013-08-13' AS DATE)),
> (CAST('1999-07-20' AS DATE)),
> (CAST('1962-07-03' AS DATE)),
> (CAST('2011-08-17' AS DATE)),
> (CAST('2011-05-16' AS DATE)),
> (CAST('1946-05-08' AS DATE)),
> (CAST('1994-02-13' AS DATE)),
> (CAST('1978-08-09' AS DATE)),
> (CAST('1978-08-09' AS DATE)),
> (CAST('1978-08-09' AS DATE)),
> (CAST('1978-08-09' AS DATE)),
> (CAST('1958-02-06' AS DATE)),
> (CAST('2012-06-11' AS DATE)),
> (CAST('2012-06-11' AS DATE)),
> (CAST('2012-06-11' AS DATE)),
> (CAST('2012-06-11' AS DATE)),
> (CAST('1998-03-26' AS DATE)),
> (CAST('1996-11-04' AS DATE)),
> (CAST('1953-09-25' AS DATE)),
> (CAST('2003-06-17' AS DATE)),
> (CAST('2003-06-17' AS DATE)),
> (CAST('2003-06-17' AS DATE)),
> (CAST('2003-06-17' AS DATE)),
> (CAST('2003-06-17' AS DATE)),
> (CAST('1980-07-05' AS DATE)),
> (CAST('1982-06-15' AS DATE)),
> (CAST('1951-05-16' AS DATE)))
> tbl(dt)
> {noformat}
> Details from Web UI Profile tab, please note that the query is still in
> STARTING state
> {noformat}
> Running Queries
> Time UserQuery State Foreman
> 05/16/2016 10:33:57
> mapr
> SELECT DISTINCT dt FROM ( VALUES(CAST('1964-03-07' AS DATE)),
> (CAST('2002-03-04' AS DATE)), (CAST('1966-09-04' AS DATE)), (CAST('199
> STARTING
> centos-01.qa.lab
> {noformat}
> There is no other useful information in drillbit.log. jstack output is
> attached here for your reference.
> The same query works fine on Postgres 9.3
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (DRILL-4679) CONVERT_FROM() json format fails if 0 rows are received from upstream operator
Aman Sinha created DRILL-4679:
-
Summary: 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
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] [Commented] (DRILL-4678) Query HANG - SELECT DISTINCT over date data
[
https://issues.apache.org/jira/browse/DRILL-4678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15284797#comment-15284797
]
Deneche A. Hakim commented on DRILL-4678:
-
>From jstack It looks like the query is still in planing phase, it doesn't look
>like it's blocked but it could be in an infinite loop. It's possible its a
>planing issue.
> Query HANG - SELECT DISTINCT over date data
> ---
>
> Key: DRILL-4678
> URL: https://issues.apache.org/jira/browse/DRILL-4678
> Project: Apache Drill
> Issue Type: Bug
> Components: Execution - Relational Operators
>Affects Versions: 1.7.0
> Environment: 4 node cluster CentOS
>Reporter: Khurram Faraaz
>Priority: Critical
> Attachments: hung_Date_Query.log
>
>
> Below query hangs
> {noformat}
> 2016-05-16 10:33:57,506 [28c65de9-9f67-dadb-5e4e-e1a12f8dda49:foreman] INFO
> o.a.drill.exec.work.foreman.Foreman - Query text for query id
> 28c65de9-9f67-dadb-5e4e-e1a12f8dda49: SELECT DISTINCT dt FROM (
> VALUES(CAST('1964-03-07' AS DATE)),
> (CAST('2002-03-04' AS DATE)),
> (CAST('1966-09-04' AS DATE)),
> (CAST('1993-08-18' AS DATE)),
> (CAST('1970-06-11' AS DATE)),
> (CAST('1970-06-11' AS DATE)),
> (CAST('1970-06-11' AS DATE)),
> (CAST('1970-06-11' AS DATE)),
> (CAST('1970-06-11' AS DATE)),
> (CAST('1959-10-23' AS DATE)),
> (CAST('1992-01-14' AS DATE)),
> (CAST('1994-07-24' AS DATE)),
> (CAST('1979-11-25' AS DATE)),
> (CAST('1945-01-14' AS DATE)),
> (CAST('1982-07-25' AS DATE)),
> (CAST('1966-09-06' AS DATE)),
> (CAST('1989-05-01' AS DATE)),
> (CAST('1996-03-08' AS DATE)),
> (CAST('1998-08-19' AS DATE)),
> (CAST('2013-08-13' AS DATE)),
> (CAST('2013-08-13' AS DATE)),
> (CAST('2013-08-13' AS DATE)),
> (CAST('2013-08-13' AS DATE)),
> (CAST('2013-08-13' AS DATE)),
> (CAST('2013-08-13' AS DATE)),
> (CAST('1999-07-20' AS DATE)),
> (CAST('1962-07-03' AS DATE)),
> (CAST('2011-08-17' AS DATE)),
> (CAST('2011-05-16' AS DATE)),
> (CAST('1946-05-08' AS DATE)),
> (CAST('1994-02-13' AS DATE)),
> (CAST('1978-08-09' AS DATE)),
> (CAST('1978-08-09' AS DATE)),
> (CAST('1978-08-09' AS DATE)),
> (CAST('1978-08-09' AS DATE)),
> (CAST('1958-02-06' AS DATE)),
> (CAST('2012-06-11' AS DATE)),
> (CAST('2012-06-11' AS DATE)),
> (CAST('2012-06-11' AS DATE)),
> (CAST('2012-06-11' AS DATE)),
> (CAST('1998-03-26' AS DATE)),
> (CAST('1996-11-04' AS DATE)),
> (CAST('1953-09-25' AS DATE)),
> (CAST('2003-06-17' AS DATE)),
> (CAST('2003-06-17' AS DATE)),
> (CAST('2003-06-17' AS DATE)),
> (CAST('2003-06-17' AS DATE)),
> (CAST('2003-06-17' AS DATE)),
> (CAST('1980-07-05' AS DATE)),
> (CAST('1982-06-15' AS DATE)),
> (CAST('1951-05-16' AS DATE)))
> tbl(dt)
> {noformat}
> Details from Web UI Profile tab, please note that the query is still in
> STARTING state
> {noformat}
> Running Queries
> Time UserQuery State Foreman
> 05/16/2016 10:33:57
> mapr
> SELECT DISTINCT dt FROM ( VALUES(CAST('1964-03-07' AS DATE)),
> (CAST('2002-03-04' AS DATE)), (CAST('1966-09-04' AS DATE)), (CAST('199
> STARTING
> centos-01.qa.lab
> {noformat}
> There is no other useful information in drillbit.log. jstack output is
> attached here for your reference.
> The same query works fine on Postgres 9.3
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DRILL-4678) Query HANG - SELECT DISTINCT over date data
[
https://issues.apache.org/jira/browse/DRILL-4678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Deneche A. Hakim updated DRILL-4678:
Component/s: (was: Execution - Relational Operators)
Query Planning & Optimization
> Query HANG - SELECT DISTINCT over date data
> ---
>
> Key: DRILL-4678
> URL: https://issues.apache.org/jira/browse/DRILL-4678
> Project: Apache Drill
> Issue Type: Bug
> Components: Query Planning & Optimization
>Affects Versions: 1.7.0
> Environment: 4 node cluster CentOS
>Reporter: Khurram Faraaz
>Priority: Critical
> Attachments: hung_Date_Query.log
>
>
> Below query hangs
> {noformat}
> 2016-05-16 10:33:57,506 [28c65de9-9f67-dadb-5e4e-e1a12f8dda49:foreman] INFO
> o.a.drill.exec.work.foreman.Foreman - Query text for query id
> 28c65de9-9f67-dadb-5e4e-e1a12f8dda49: SELECT DISTINCT dt FROM (
> VALUES(CAST('1964-03-07' AS DATE)),
> (CAST('2002-03-04' AS DATE)),
> (CAST('1966-09-04' AS DATE)),
> (CAST('1993-08-18' AS DATE)),
> (CAST('1970-06-11' AS DATE)),
> (CAST('1970-06-11' AS DATE)),
> (CAST('1970-06-11' AS DATE)),
> (CAST('1970-06-11' AS DATE)),
> (CAST('1970-06-11' AS DATE)),
> (CAST('1959-10-23' AS DATE)),
> (CAST('1992-01-14' AS DATE)),
> (CAST('1994-07-24' AS DATE)),
> (CAST('1979-11-25' AS DATE)),
> (CAST('1945-01-14' AS DATE)),
> (CAST('1982-07-25' AS DATE)),
> (CAST('1966-09-06' AS DATE)),
> (CAST('1989-05-01' AS DATE)),
> (CAST('1996-03-08' AS DATE)),
> (CAST('1998-08-19' AS DATE)),
> (CAST('2013-08-13' AS DATE)),
> (CAST('2013-08-13' AS DATE)),
> (CAST('2013-08-13' AS DATE)),
> (CAST('2013-08-13' AS DATE)),
> (CAST('2013-08-13' AS DATE)),
> (CAST('2013-08-13' AS DATE)),
> (CAST('1999-07-20' AS DATE)),
> (CAST('1962-07-03' AS DATE)),
> (CAST('2011-08-17' AS DATE)),
> (CAST('2011-05-16' AS DATE)),
> (CAST('1946-05-08' AS DATE)),
> (CAST('1994-02-13' AS DATE)),
> (CAST('1978-08-09' AS DATE)),
> (CAST('1978-08-09' AS DATE)),
> (CAST('1978-08-09' AS DATE)),
> (CAST('1978-08-09' AS DATE)),
> (CAST('1958-02-06' AS DATE)),
> (CAST('2012-06-11' AS DATE)),
> (CAST('2012-06-11' AS DATE)),
> (CAST('2012-06-11' AS DATE)),
> (CAST('2012-06-11' AS DATE)),
> (CAST('1998-03-26' AS DATE)),
> (CAST('1996-11-04' AS DATE)),
> (CAST('1953-09-25' AS DATE)),
> (CAST('2003-06-17' AS DATE)),
> (CAST('2003-06-17' AS DATE)),
> (CAST('2003-06-17' AS DATE)),
> (CAST('2003-06-17' AS DATE)),
> (CAST('2003-06-17' AS DATE)),
> (CAST('1980-07-05' AS DATE)),
> (CAST('1982-06-15' AS DATE)),
> (CAST('1951-05-16' AS DATE)))
> tbl(dt)
> {noformat}
> Details from Web UI Profile tab, please note that the query is still in
> STARTING state
> {noformat}
> Running Queries
> Time UserQuery State Foreman
> 05/16/2016 10:33:57
> mapr
> SELECT DISTINCT dt FROM ( VALUES(CAST('1964-03-07' AS DATE)),
> (CAST('2002-03-04' AS DATE)), (CAST('1966-09-04' AS DATE)), (CAST('199
> STARTING
> centos-01.qa.lab
> {noformat}
> There is no other useful information in drillbit.log. jstack output is
> attached here for your reference.
> The same query works fine on Postgres 9.3
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DRILL-4680) Cancel query that is in Planing state - user RPC thread of the foreman Drillbit will block waiting for query to finish planing
[ https://issues.apache.org/jira/browse/DRILL-4680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Khurram Faraaz updated DRILL-4680: -- Priority: Critical (was: Major) > Cancel query that is in Planing state - user RPC thread of the foreman > Drillbit will block waiting for query to finish planing > -- > > Key: DRILL-4680 > URL: https://issues.apache.org/jira/browse/DRILL-4680 > Project: Apache Drill > Issue Type: Bug > Components: Query Planning & Optimization >Affects Versions: 1.7.0 > Environment: 4 node cluster CentOS >Reporter: Khurram Faraaz >Priority: Critical > > Unfortunately, if you try to cancel a query that's still in planing, the user > RPC thread of the foreman Drillbit will block waiting for the query to finish > planing, this will cause any other query submitted to the same Drillbit to > block as well. It's a known issue (actually a serious Drill limitation). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (DRILL-4680) Cancel query that is in Planing state - user RPC thread of the foreman Drillbit will block waiting for query to finish planing
Khurram Faraaz created DRILL-4680: - Summary: Cancel query that is in Planing state - user RPC thread of the foreman Drillbit will block waiting for query to finish planing Key: DRILL-4680 URL: https://issues.apache.org/jira/browse/DRILL-4680 Project: Apache Drill Issue Type: Bug Components: Query Planning & Optimization Affects Versions: 1.7.0 Environment: 4 node cluster CentOS Reporter: Khurram Faraaz Unfortunately, if you try to cancel a query that's still in planing, the user RPC thread of the foreman Drillbit will block waiting for the query to finish planing, this will cause any other query submitted to the same Drillbit to block as well. It's a known issue (actually a serious Drill limitation). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (DRILL-4680) Cancel query that is in Planing state - user RPC thread of the foreman Drillbit will block waiting for query to finish planing
[ https://issues.apache.org/jira/browse/DRILL-4680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudheesh Katkam resolved DRILL-4680. Resolution: Duplicate Refer to DRILL-4355 to check for current resolution. > Cancel query that is in Planing state - user RPC thread of the foreman > Drillbit will block waiting for query to finish planing > -- > > Key: DRILL-4680 > URL: https://issues.apache.org/jira/browse/DRILL-4680 > Project: Apache Drill > Issue Type: Bug > Components: Query Planning & Optimization >Affects Versions: 1.7.0 > Environment: 4 node cluster CentOS >Reporter: Khurram Faraaz >Priority: Critical > > Unfortunately, if you try to cancel a query that's still in planing, the user > RPC thread of the foreman Drillbit will block waiting for the query to finish > planing, this will cause any other query submitted to the same Drillbit to > block as well. It's a known issue (actually a serious Drill limitation). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (DRILL-4680) Cancel query that is in Planing state - user RPC thread of the foreman Drillbit will block waiting for query to finish planing
[ https://issues.apache.org/jira/browse/DRILL-4680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15284866#comment-15284866 ] Sudheesh Katkam edited comment on DRILL-4680 at 5/16/16 5:25 PM: - Refer to DRILL-4355 for current resolution. was (Author: sudheeshkatkam): Refer to DRILL-4355 to check for current resolution. > Cancel query that is in Planing state - user RPC thread of the foreman > Drillbit will block waiting for query to finish planing > -- > > Key: DRILL-4680 > URL: https://issues.apache.org/jira/browse/DRILL-4680 > Project: Apache Drill > Issue Type: Bug > Components: Query Planning & Optimization >Affects Versions: 1.7.0 > Environment: 4 node cluster CentOS >Reporter: Khurram Faraaz >Priority: Critical > > Unfortunately, if you try to cancel a query that's still in planing, the user > RPC thread of the foreman Drillbit will block waiting for the query to finish > planing, this will cause any other query submitted to the same Drillbit to > block as well. It's a known issue (actually a serious Drill limitation). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DRILL-4355) Query can not be cancelled when it is in the planning phase
[ https://issues.apache.org/jira/browse/DRILL-4355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Khurram Faraaz updated DRILL-4355: -- Priority: Critical (was: Major) > Query can not be cancelled when it is in the planning phase > --- > > Key: DRILL-4355 > URL: https://issues.apache.org/jira/browse/DRILL-4355 > Project: Apache Drill > Issue Type: Bug > Components: Execution - Flow >Reporter: Victoria Markman >Priority: Critical > > It's a known issue, but I could not find a bug ... Please close it as a > duplicate if there is one. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DRILL-4680) Cancel query that is in Planing state - user RPC thread of the foreman Drillbit will block waiting for query to finish planing
[ https://issues.apache.org/jira/browse/DRILL-4680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15284884#comment-15284884 ] Khurram Faraaz commented on DRILL-4680: --- As of today DRILL-4355 is Open and unresolved. > Cancel query that is in Planing state - user RPC thread of the foreman > Drillbit will block waiting for query to finish planing > -- > > Key: DRILL-4680 > URL: https://issues.apache.org/jira/browse/DRILL-4680 > Project: Apache Drill > Issue Type: Bug > Components: Query Planning & Optimization >Affects Versions: 1.7.0 > Environment: 4 node cluster CentOS >Reporter: Khurram Faraaz >Priority: Critical > > Unfortunately, if you try to cancel a query that's still in planing, the user > RPC thread of the foreman Drillbit will block waiting for the query to finish > planing, this will cause any other query submitted to the same Drillbit to > block as well. It's a known issue (actually a serious Drill limitation). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DRILL-4678) Query HANG - SELECT DISTINCT over date data
[
https://issues.apache.org/jira/browse/DRILL-4678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15285187#comment-15285187
]
Julian Hyde commented on DRILL-4678:
>From the stack it looks as if it is not hung, but is hitting a performance bug
>evaluating metadata (the estimate of the number of distinct rows). I suspect
>something is O(n ^ 2) or worse in the size of the VALUES clause.
You can confirm that the large VALUES clause is the main contributing factor by
reducing its size and seeing what that does to the running time.
CALCITE-604 and CALCITE-1147 might both improve this situation, so it's worth
finding out whether they're in that Drill version. They might also make the
situation worse, caching being somewhat of a blunt instrument.
See if you can reproduce this bug in just Calcite. (E.g. in the PlannerTest.)
> Query HANG - SELECT DISTINCT over date data
> ---
>
> Key: DRILL-4678
> URL: https://issues.apache.org/jira/browse/DRILL-4678
> Project: Apache Drill
> Issue Type: Bug
> Components: Query Planning & Optimization
>Affects Versions: 1.7.0
> Environment: 4 node cluster CentOS
>Reporter: Khurram Faraaz
>Priority: Critical
> Attachments: hung_Date_Query.log
>
>
> Below query hangs
> {noformat}
> 2016-05-16 10:33:57,506 [28c65de9-9f67-dadb-5e4e-e1a12f8dda49:foreman] INFO
> o.a.drill.exec.work.foreman.Foreman - Query text for query id
> 28c65de9-9f67-dadb-5e4e-e1a12f8dda49: SELECT DISTINCT dt FROM (
> VALUES(CAST('1964-03-07' AS DATE)),
> (CAST('2002-03-04' AS DATE)),
> (CAST('1966-09-04' AS DATE)),
> (CAST('1993-08-18' AS DATE)),
> (CAST('1970-06-11' AS DATE)),
> (CAST('1970-06-11' AS DATE)),
> (CAST('1970-06-11' AS DATE)),
> (CAST('1970-06-11' AS DATE)),
> (CAST('1970-06-11' AS DATE)),
> (CAST('1959-10-23' AS DATE)),
> (CAST('1992-01-14' AS DATE)),
> (CAST('1994-07-24' AS DATE)),
> (CAST('1979-11-25' AS DATE)),
> (CAST('1945-01-14' AS DATE)),
> (CAST('1982-07-25' AS DATE)),
> (CAST('1966-09-06' AS DATE)),
> (CAST('1989-05-01' AS DATE)),
> (CAST('1996-03-08' AS DATE)),
> (CAST('1998-08-19' AS DATE)),
> (CAST('2013-08-13' AS DATE)),
> (CAST('2013-08-13' AS DATE)),
> (CAST('2013-08-13' AS DATE)),
> (CAST('2013-08-13' AS DATE)),
> (CAST('2013-08-13' AS DATE)),
> (CAST('2013-08-13' AS DATE)),
> (CAST('1999-07-20' AS DATE)),
> (CAST('1962-07-03' AS DATE)),
> (CAST('2011-08-17' AS DATE)),
> (CAST('2011-05-16' AS DATE)),
> (CAST('1946-05-08' AS DATE)),
> (CAST('1994-02-13' AS DATE)),
> (CAST('1978-08-09' AS DATE)),
> (CAST('1978-08-09' AS DATE)),
> (CAST('1978-08-09' AS DATE)),
> (CAST('1978-08-09' AS DATE)),
> (CAST('1958-02-06' AS DATE)),
> (CAST('2012-06-11' AS DATE)),
> (CAST('2012-06-11' AS DATE)),
> (CAST('2012-06-11' AS DATE)),
> (CAST('2012-06-11' AS DATE)),
> (CAST('1998-03-26' AS DATE)),
> (CAST('1996-11-04' AS DATE)),
> (CAST('1953-09-25' AS DATE)),
> (CAST('2003-06-17' AS DATE)),
> (CAST('2003-06-17' AS DATE)),
> (CAST('2003-06-17' AS DATE)),
> (CAST('2003-06-17' AS DATE)),
> (CAST('2003-06-17' AS DATE)),
> (CAST('1980-07-05' AS DATE)),
> (CAST('1982-06-15' AS DATE)),
> (CAST('1951-05-16' AS DATE)))
> tbl(dt)
> {noformat}
> Details from Web UI Profile tab, please note that the query is still in
> STARTING state
> {noformat}
> Running Queries
> Time UserQuery State Foreman
> 05/16/2016 10:33:57
> mapr
> SELECT DISTINCT dt FROM ( VALUES(CAST('1964-03-07' AS DATE)),
> (CAST('2002-03-04' AS DATE)), (CAST('1966-09-04' AS DATE)), (CAST('199
> STARTING
> centos-01.qa.lab
> {noformat}
> There is no other useful information in drillbit.log. jstack output is
> attached here for your reference.
> The same query works fine on Postgres 9.3
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DRILL-4657) Rank() will return wrong results if a frame of data is too big (more than 2 batches)
[ https://issues.apache.org/jira/browse/DRILL-4657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Suresh Ollala updated DRILL-4657: - Reviewer: Abhishek Girish > Rank() will return wrong results if a frame of data is too big (more than 2 > batches) > > > Key: DRILL-4657 > URL: https://issues.apache.org/jira/browse/DRILL-4657 > Project: Apache Drill > Issue Type: Bug > Components: Execution - Relational Operators >Affects Versions: 1.3.0 >Reporter: Deneche A. Hakim >Assignee: Deneche A. Hakim >Priority: Critical > Fix For: 1.7.0 > > > When you run a query with RANK, and one particular frame is too long to fit > in 2 batches of data, you will get wrong result. > I was able to reproduce the issue in a unit test, thanks to the fact that we > can control the size of the batches processed by the window operator. I will > post a fix soon along with the unit test -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (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:comment-tabpanel&focusedCommentId=15285341#comment-15285341
]
ASF GitHub Bot commented on DRILL-4676:
---
Github user hnfgns commented on a diff in the pull request:
https://github.com/apache/drill/pull/503#discussion_r63428428
--- Diff:
exec/java-exec/src/main/java/org/apache/drill/exec/work/foreman/Foreman.java ---
@@ -1221,6 +1223,12 @@ public void interrupted(final InterruptedException
e) {
* to the user
*/
public void moveToState(final QueryState newState, final Exception ex)
{
+ // if the current thread is the foreman thread, throw an exception
+ // otherwise the foreman will be blocked forever on
acceptExternalEvents
+ if (myThreadRef == Thread.currentThread()) {
--- End diff --
Well, Foreman does not call moveToState in common path but when it fails
then it could. My point is instead of hacking the method to throw an exception
if the thread is foreman we should release the latch and handle the exception
in foreman#run. What I mean is
Foreman#run() {
```
try {
do sth
} catch(ex) {
release latch
handleException(ex)
} finally {
...
}
```
> 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: Sudheesh Katkam
> 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] [Commented] (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:comment-tabpanel&focusedCommentId=15285368#comment-15285368
]
ASF GitHub Bot commented on DRILL-4676:
---
Github user adeneche commented on a diff in the pull request:
https://github.com/apache/drill/pull/503#discussion_r63430234
--- Diff:
exec/java-exec/src/main/java/org/apache/drill/exec/work/foreman/Foreman.java ---
@@ -1221,6 +1223,12 @@ public void interrupted(final InterruptedException
e) {
* to the user
*/
public void moveToState(final QueryState newState, final Exception ex)
{
+ // if the current thread is the foreman thread, throw an exception
+ // otherwise the foreman will be blocked forever on
acceptExternalEvents
+ if (myThreadRef == Thread.currentThread()) {
--- End diff --
This won't work when submitting remote fragments as the moveToState method
can be called either by the foreman thread or by an rpc thread.
Anyway, I'm working on a better fix that would remove the latch completely.
> 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: Sudheesh Katkam
> 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] [Commented] (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:comment-tabpanel&focusedCommentId=15285370#comment-15285370
]
ASF GitHub Bot commented on DRILL-4676:
---
Github user hnfgns commented on a diff in the pull request:
https://github.com/apache/drill/pull/503#discussion_r63430594
--- Diff:
exec/java-exec/src/main/java/org/apache/drill/exec/work/foreman/Foreman.java ---
@@ -1221,6 +1223,12 @@ public void interrupted(final InterruptedException
e) {
* to the user
*/
public void moveToState(final QueryState newState, final Exception ex)
{
+ // if the current thread is the foreman thread, throw an exception
+ // otherwise the foreman will be blocked forever on
acceptExternalEvents
+ if (myThreadRef == Thread.currentThread()) {
--- End diff --
Let me ask you this: what was the primary cause of deadlock came out of
your investigation?
> 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: Sudheesh Katkam
> 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] [Commented] (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:comment-tabpanel&focusedCommentId=15285380#comment-15285380
]
ASF GitHub Bot commented on DRILL-4676:
---
Github user adeneche commented on a diff in the pull request:
https://github.com/apache/drill/pull/503#discussion_r63431381
--- Diff:
exec/java-exec/src/main/java/org/apache/drill/exec/work/foreman/Foreman.java ---
@@ -1221,6 +1223,12 @@ public void interrupted(final InterruptedException
e) {
* to the user
*/
public void moveToState(final QueryState newState, final Exception ex)
{
+ // if the current thread is the foreman thread, throw an exception
+ // otherwise the foreman will be blocked forever on
acceptExternalEvents
+ if (myThreadRef == Thread.currentThread()) {
--- End diff --
We were assuming that the Foreman thread would never call
Foreman.StateListener.moveToState() and it would be called by another (rpc)
thread instead.
It turns out when the foreman is submitting remote fragments, RpcBus.send()
could actually cause the foreman thread to call moveToState directly
> 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: Sudheesh Katkam
> 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] [Commented] (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:comment-tabpanel&focusedCommentId=15285580#comment-15285580 ] ASF GitHub Bot commented on DRILL-4676: --- Github user adeneche commented on the pull request: https://github.com/apache/drill/pull/503#issuecomment-219571472 This is an alternative change that removes the blocking latch from Foreman. There is still a possibility for the foreman thread to block forever in case of a bug but this should no longer cause rpc threads to block as well > 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: Sudheesh Katkam > 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] [Commented] (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:comment-tabpanel&focusedCommentId=15285605#comment-15285605 ] ASF GitHub Bot commented on DRILL-4676: --- Github user hnfgns commented on the pull request: https://github.com/apache/drill/pull/503#issuecomment-219573757 I see that you are enabling task hand-off for the first task in the serializer as well. I am not convinced that this approach will for sure fix the deadlock case for RPCs and foreman failure case. I do not have time now but I will think about this issue. > 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: Sudheesh Katkam > 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] [Commented] (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:comment-tabpanel&focusedCommentId=15285619#comment-15285619
]
ASF GitHub Bot commented on DRILL-4676:
---
Github user sudheeshkatkam commented on a diff in the pull request:
https://github.com/apache/drill/pull/503#discussion_r63442039
--- Diff:
exec/java-exec/src/main/java/org/apache/drill/exec/work/foreman/Foreman.java ---
@@ -296,7 +295,7 @@ public void run() {
* would wait on the cancelling thread to signal a resume and the
cancelling thread would wait on the Foreman
* to accept events.
*/
- acceptExternalEvents.countDown();
+ stateSwitch.start();
--- End diff --
This defers all state transitions until the thread is done. This changes
the behavior when queuing is enabled, the user will not know if the query has
moved from ENQUEUED to STARTING.
> 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: Sudheesh Katkam
> 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] [Commented] (DRILL-4573) Zero copy LIKE, REGEXP_MATCHES, SUBSTR
[ https://issues.apache.org/jira/browse/DRILL-4573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15285621#comment-15285621 ] ASF GitHub Bot commented on DRILL-4573: --- Github user jcmcote commented on the pull request: https://github.com/apache/drill/pull/502#issuecomment-219576551 @jinfengni can you apply this pull request. There's build issue but looks to be related to pom.xml files which I have not changed.. > Zero copy LIKE, REGEXP_MATCHES, SUBSTR > -- > > Key: DRILL-4573 > URL: https://issues.apache.org/jira/browse/DRILL-4573 > Project: Apache Drill > Issue Type: Improvement >Reporter: jean-claude >Priority: Minor > Fix For: 1.7.0 > > Attachments: DRILL-4573-3.patch.txt, DRILL-4573.patch.txt > > > All the functions using the java.util.regex.Matcher are currently creating > Java string objects to pass into the matcher.reset(). > However this creates unnecessary copy of the bytes and a Java string object. > The matcher uses a CharSequence, so instead of making a copy we can create an > adapter from the DrillBuffer to the CharSequence interface. > Gains of 25% in execution speed are possible when going over VARCHAR of 36 > chars. The gain will be proportional to the size of the VARCHAR. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DRILL-4573) Zero copy LIKE, REGEXP_MATCHES, SUBSTR
[ https://issues.apache.org/jira/browse/DRILL-4573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15285627#comment-15285627 ] ASF GitHub Bot commented on DRILL-4573: --- Github user jinfengni commented on the pull request: https://github.com/apache/drill/pull/502#issuecomment-219577333 @jcmcote , I'll take a look at the patch shortly. You are right that the build issue should not be caused by your code change. > Zero copy LIKE, REGEXP_MATCHES, SUBSTR > -- > > Key: DRILL-4573 > URL: https://issues.apache.org/jira/browse/DRILL-4573 > Project: Apache Drill > Issue Type: Improvement >Reporter: jean-claude >Priority: Minor > Fix For: 1.7.0 > > Attachments: DRILL-4573-3.patch.txt, DRILL-4573.patch.txt > > > All the functions using the java.util.regex.Matcher are currently creating > Java string objects to pass into the matcher.reset(). > However this creates unnecessary copy of the bytes and a Java string object. > The matcher uses a CharSequence, so instead of making a copy we can create an > adapter from the DrillBuffer to the CharSequence interface. > Gains of 25% in execution speed are possible when going over VARCHAR of 36 > chars. The gain will be proportional to the size of the VARCHAR. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (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:comment-tabpanel&focusedCommentId=15285661#comment-15285661
]
ASF GitHub Bot commented on DRILL-4676:
---
Github user adeneche commented on a diff in the pull request:
https://github.com/apache/drill/pull/503#discussion_r63444805
--- Diff:
exec/java-exec/src/main/java/org/apache/drill/exec/work/foreman/Foreman.java ---
@@ -296,7 +295,7 @@ public void run() {
* would wait on the cancelling thread to signal a resume and the
cancelling thread would wait on the Foreman
* to accept events.
*/
- acceptExternalEvents.countDown();
+ stateSwitch.start();
--- End diff --
that is true indeed, I didn't notice the Foreman was also using the event
queue before it counted down the latch. I will update the fix to respect this
behavior
> 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: Sudheesh Katkam
> 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] [Commented] (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:comment-tabpanel&focusedCommentId=15285666#comment-15285666
]
ASF GitHub Bot commented on DRILL-4676:
---
Github user sudheeshkatkam commented on a diff in the pull request:
https://github.com/apache/drill/pull/503#discussion_r63444985
--- Diff:
exec/java-exec/src/main/java/org/apache/drill/exec/work/foreman/Foreman.java ---
@@ -1221,8 +1220,6 @@ public void interrupted(final InterruptedException e)
{
* to the user
*/
public void moveToState(final QueryState newState, final Exception ex)
{
--- End diff --
With this change, compared to Foreman#moveToState, this listener provides
no additional functionality. Please remove this class, and update the docs for
Foreman#moveToState accordingly.
> 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: Sudheesh Katkam
> 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] [Commented] (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:comment-tabpanel&focusedCommentId=15285664#comment-15285664
]
ASF GitHub Bot commented on DRILL-4676:
---
Github user sudheeshkatkam commented on a diff in the pull request:
https://github.com/apache/drill/pull/503#discussion_r63444977
--- Diff: common/src/main/java/org/apache/drill/common/EventProcessor.java
---
@@ -57,25 +58,35 @@ public EventProcessor() {
*/
public void sendEvent(final T newEvent) {
synchronized (queuedEvents) {
- if (isProcessing) {
-queuedEvents.addLast(newEvent);
+ queuedEvents.addLast(newEvent);
+ if (!started || isProcessing) {
return;
}
isProcessing = true;
}
+processEvents();
+ }
+
+ public void start() {
--- End diff --
Please add docs here.
> 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: Sudheesh Katkam
> 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] [Commented] (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:comment-tabpanel&focusedCommentId=15285662#comment-15285662
]
ASF GitHub Bot commented on DRILL-4676:
---
Github user sudheeshkatkam commented on a diff in the pull request:
https://github.com/apache/drill/pull/503#discussion_r63444968
--- Diff: common/src/main/java/org/apache/drill/common/EventProcessor.java
---
@@ -37,6 +37,7 @@
public abstract class EventProcessor {
private final LinkedList queuedEvents = new LinkedList<>();
private volatile boolean isProcessing = false;
+ private volatile boolean started;
--- End diff --
Explicitly set to false as above.
> 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: Sudheesh Katkam
> 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] [Commented] (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:comment-tabpanel&focusedCommentId=15285663#comment-15285663
]
ASF GitHub Bot commented on DRILL-4676:
---
Github user sudheeshkatkam commented on a diff in the pull request:
https://github.com/apache/drill/pull/503#discussion_r63444973
--- Diff: common/src/main/java/org/apache/drill/common/EventProcessor.java
---
@@ -57,25 +58,35 @@ public EventProcessor() {
*/
public void sendEvent(final T newEvent) {
synchronized (queuedEvents) {
- if (isProcessing) {
-queuedEvents.addLast(newEvent);
+ queuedEvents.addLast(newEvent);
+ if (!started || isProcessing) {
--- End diff --
Update the method docs.
> 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: Sudheesh Katkam
> 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] [Commented] (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:comment-tabpanel&focusedCommentId=15285665#comment-15285665
]
ASF GitHub Bot commented on DRILL-4676:
---
Github user sudheeshkatkam commented on a diff in the pull request:
https://github.com/apache/drill/pull/503#discussion_r63444982
--- Diff: common/src/main/java/org/apache/drill/common/EventProcessor.java
---
@@ -57,25 +58,35 @@ public EventProcessor() {
*/
public void sendEvent(final T newEvent) {
synchronized (queuedEvents) {
- if (isProcessing) {
-queuedEvents.addLast(newEvent);
+ queuedEvents.addLast(newEvent);
+ if (!started || isProcessing) {
return;
}
isProcessing = true;
}
+processEvents();
+ }
+
+ public void start() {
+if (started) {
+ return;
+}
+
+synchronized (queuedEvents) {
+ started = true;
+ isProcessing = true;
+}
+
+processEvents();
+ }
+
+ private void processEvents() {
@SuppressWarnings("resource")
final DeferredException deferredException = new DeferredException();
-T event = newEvent;
+T event;
--- End diff --
Move this declaration inside the loop.
> 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: Sudheesh Katkam
> 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] [Created] (DRILL-4681) ChannelClosedException causes all queries which are communicating on that channel to fail
Rahul Challapalli created DRILL-4681: Summary: ChannelClosedException causes all queries which are communicating on that channel to fail Key: DRILL-4681 URL: https://issues.apache.org/jira/browse/DRILL-4681 Project: Apache Drill Issue Type: Bug Components: Execution - Flow, Execution - RPC Affects Versions: 1.7.0 Reporter: Rahul Challapalli commit # : 09b262776e965ea17a6a863801f7e1ee3e5b3d5a Below is what I am describing: 1. One of the fragments cause a channel closed exception (due to an OOM or some other condition) 2. Drill fails all other fragments which are running at that time even though the fragments themselves eventually run to completion. At a high concurrency this could lead a lot of query failures. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (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:comment-tabpanel&focusedCommentId=15285689#comment-15285689 ] ASF GitHub Bot commented on DRILL-4676: --- Github user adeneche commented on the pull request: https://github.com/apache/drill/pull/503#issuecomment-219583987 I made a quick change to address Sudheesh concern about deferring processing events when the query is queued. This is a WIP to see if I am not missing anything obvious, will clean/rename/document once we agree this is a correct fix > 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: Sudheesh Katkam > 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)
