[jira] [Updated] (HIVE-28298) TestQueryShutdownHooks to run on Tez
[
https://issues.apache.org/jira/browse/HIVE-28298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
László Bodor updated HIVE-28298:
Description:
this test got stuck while running in the scope of HIVE-27972, need to check
jstack showed stacks like:
{code}
"HiveServer2-Background-Pool: Thread-155" #155 prio=5 os_prio=31
tid=0x7fa59f5e4800 nid=0x8027 waiting for monitor entry [0x700010ace000]
java.lang.Thread.State: BLOCKED (on object monitor)
at
org.apache.hadoop.hive.ql.exec.tez.TezTask$SyncDagClient.tryKillDAG(TezTask.java:870)
- waiting to lock <0x0007be5c98f8> (a
org.apache.tez.dag.api.client.DAGClientImplLocal)
at
org.apache.hadoop.hive.ql.exec.tez.monitoring.TezJobMonitor.monitorExecution(TezJobMonitor.java:278)
at org.apache.hadoop.hive.ql.exec.tez.TezTask.execute(TezTask.java:271)
at org.apache.hadoop.hive.ql.exec.Task.executeTask(Task.java:214)
at
org.apache.hadoop.hive.ql.exec.TaskRunner.runSequential(TaskRunner.java:105)
at org.apache.hadoop.hive.ql.Executor.launchTask(Executor.java:354)
at org.apache.hadoop.hive.ql.Executor.launchTasks(Executor.java:327)
at org.apache.hadoop.hive.ql.Executor.runTasks(Executor.java:244)
at org.apache.hadoop.hive.ql.Executor.execute(Executor.java:105)
at org.apache.hadoop.hive.ql.Driver.execute(Driver.java:367)
at org.apache.hadoop.hive.ql.Driver.runInternal(Driver.java:205)
at org.apache.hadoop.hive.ql.Driver.run(Driver.java:154)
at org.apache.hadoop.hive.ql.Driver.run(Driver.java:149)
at
org.apache.hadoop.hive.ql.reexec.ReExecDriver.run(ReExecDriver.java:185)
at
org.apache.hive.service.cli.operation.SQLOperation.runQuery(SQLOperation.java:236)
at
org.apache.hive.service.cli.operation.SQLOperation.access$500(SQLOperation.java:90)
at
org.apache.hive.service.cli.operation.SQLOperation$BackgroundWork$1.run(SQLOperation.java:336)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:422)
at
org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1899)
at
org.apache.hive.service.cli.operation.SQLOperation$BackgroundWork.run(SQLOperation.java:356)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
"f7b8e319-d882-4734-b036-1bb2da4b2783 main" #1 prio=5 os_prio=31
tid=0x7fa60e80b800 nid=0x1b03 waiting on condition [0x7e32a000]
java.lang.Thread.State: TIMED_WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x0007be3d0578> (a
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
at
org.apache.tez.dag.app.dag.impl.DAGImpl.getDAGStatus(DAGImpl.java:982)
at
org.apache.tez.dag.api.client.DAGClientHandler.getDAGStatus(DAGClientHandler.java:73)
at org.apache.tez.client.LocalClient$2.apply(LocalClient.java:441)
at org.apache.tez.client.LocalClient$2.apply(LocalClient.java:437)
at
org.apache.tez.dag.api.client.DAGClientImplLocal.getDAGStatusInternal(DAGClientImplLocal.java:53)
at
org.apache.tez.dag.api.client.DAGClientImpl.getDAGStatus(DAGClientImpl.java:232)
at
org.apache.tez.dag.api.client.DAGClientImpl._waitForCompletionWithStatusUpdates(DAGClientImpl.java:583)
at
org.apache.tez.dag.api.client.DAGClientImpl.waitForCompletion(DAGClientImpl.java:375)
at
org.apache.hadoop.hive.ql.exec.tez.TezTask$SyncDagClient.waitForCompletion(TezTask.java:877)
- locked <0x0007be5c98f8> (a
org.apache.tez.dag.api.client.DAGClientImplLocal)
at
org.apache.hadoop.hive.ql.exec.tez.TezTask.closeDagClientOnCancellation(TezTask.java:432)
at org.apache.hadoop.hive.ql.exec.tez.TezTask.shutdown(TezTask.java:805)
at org.apache.hadoop.hive.ql.TaskQueue.shutdown(TaskQueue.java:138)
- locked <0x0007be2a20b8> (a org.apache.hadoop.hive.ql.TaskQueue)
at org.apache.hadoop.hive.ql.Driver.releaseTaskQueue(Driver.java:802)
at org.apache.hadoop.hive.ql.Driver.close(Driver.java:779)
at
org.apache.hadoop.hive.ql.reexec.ReExecDriver.close(ReExecDriver.java:268)
at
org.apache.hive.service.cli.operation.SQLOperation.cleanup(SQLOperation.java:409)
- locked <0x0007be5994c0> (a
org.apach
[jira] [Created] (HIVE-28298) TestQueryShutdownHooks to run on Tez
László Bodor created HIVE-28298: --- Summary: TestQueryShutdownHooks to run on Tez Key: HIVE-28298 URL: https://issues.apache.org/jira/browse/HIVE-28298 Project: Hive Issue Type: Sub-task Reporter: László Bodor -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (HIVE-28294) drop database cascade operation can skip client side filtering while fetching tables in db
[ https://issues.apache.org/jira/browse/HIVE-28294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated HIVE-28294: -- Labels: pull-request-available (was: ) > drop database cascade operation can skip client side filtering while fetching > tables in db > -- > > Key: HIVE-28294 > URL: https://issues.apache.org/jira/browse/HIVE-28294 > Project: Hive > Issue Type: Bug > Components: HiveServer2 >Reporter: Sai Hemanth Gantasala >Assignee: Sai Hemanth Gantasala >Priority: Major > Labels: pull-request-available > > Drop database cascade operation fetches all tables in the DB, while doing so > we perform client-side filtering on the tables. We can avoid client-side > filtering as we anyway authorize on the tables in the DB for the drop > operation. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work started] (HIVE-28297) Unify table pattern definition in Hive MetaStore
[
https://issues.apache.org/jira/browse/HIVE-28297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on HIVE-28297 started by Wechar.
-
> Unify table pattern definition in Hive MetaStore
>
>
> Key: HIVE-28297
> URL: https://issues.apache.org/jira/browse/HIVE-28297
> Project: Hive
> Issue Type: Improvement
> Components: Hive
>Reporter: Wechar
>Assignee: Wechar
>Priority: Major
>
> *Current Situation*
> There are two cases for table pattern in Hive:
> - Case 1: Wildcards ('*' and '|)
> It's replaced by SQL type like expressions with '%' and '_' since Hive 4.0.0,
> details in HIVE-23359.
> DDL documents:
> https://cwiki.apache.org/confluence/display/Hive/LanguageManual+DDL#LanguageManualDDL-Show
> - Case 2: Java regular expression
> It's declared in hive code:
> [https://github.com/apache/hive/blob/45867be6cb5308566e4cf16c7b4cf8081085b58c/ql/src/java/org/apache/hadoop/hive/ql/metadata/Hive.java#L1882-L1894],
> and also match the jdo {{matches(String pattern)}} method:
> [https://www.datanucleus.org/products/accessplatform/jdo/query.html]
> *Issues*
> The different definitions cause the misuse of table pattern, in some codes it
> use * to represent match everything, while it use .* in other codes.
> The misuse would cause the wrong result because both client and server side
> of HMS need a trick handle for '*' with code like:
> {code:java}
> patterns.split("\\|")
> pattern.replaceAll("\\*", ".*"))
> {code}
> *Action*
> We should honor the definition in HMS of Case 2, because Case 1 is just the
> frontend of SQL, and it has been replaced.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (HIVE-28297) Unify table pattern definition in Hive MetaStore
[
https://issues.apache.org/jira/browse/HIVE-28297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wechar updated HIVE-28297:
--
Description:
*Current Situation*
There are two cases for table pattern in Hive:
- Case 1: Wildcards ('*' and '|)
It's replaced by SQL type like expressions with '%' and '_' since Hive 4.0.0,
details in HIVE-23359.
DDL documents:
https://cwiki.apache.org/confluence/display/Hive/LanguageManual+DDL#LanguageManualDDL-Show
- Case 2: Java regular expression
It's declared in hive code:
[https://github.com/apache/hive/blob/45867be6cb5308566e4cf16c7b4cf8081085b58c/ql/src/java/org/apache/hadoop/hive/ql/metadata/Hive.java#L1882-L1894],
and also match the jdo {{matches(String pattern)}} method:
[https://www.datanucleus.org/products/accessplatform/jdo/query.html]
*Issues*
The different definitions cause the misuse of table pattern, in some codes it
use * to represent match everything, while it use .* in other codes.
The misuse would cause the wrong result because both client and server side of
HMS need a trick handle for '*' with code like:
{code:java}
patterns.split("\\|")
pattern.replaceAll("\\*", ".*"))
{code}
*Action*
We should honor the definition in HMS of Case 2, because Case 1 is just the
frontend of SQL, and it has been replaced.
was:
*Current Situation*
There are two cases for table pattern in Hive:
- Case 1: Wildcards ('*' and '|)
It's replaced by SQL type like expressions with '%' and '_' since Hive 4.0.0,
details in HIVE-23359
- Case 2: Java regular expression
It's declared in hive code:
[https://github.com/apache/hive/blob/45867be6cb5308566e4cf16c7b4cf8081085b58c/ql/src/java/org/apache/hadoop/hive/ql/metadata/Hive.java#L1882-L1894],
and also match the jdo {{matches(String pattern)}} method:
[https://www.datanucleus.org/products/accessplatform/jdo/query.html]
*Issues*
The different definitions cause the misuse of table pattern, in some codes it
use * to represent match everything, while it use .* in other codes.
The misuse would cause the wrong result because both client and server side of
HMS need a trick handle for '*' with code like:
{code:java}
patterns.split("\\|")
pattern.replaceAll("\\*", ".*"))
{code}
*Action*
We should honor the definition in HMS of Case 2, because Case 1 is just the
frontend of SQL, and it has been replaced.
> Unify table pattern definition in Hive MetaStore
>
>
> Key: HIVE-28297
> URL: https://issues.apache.org/jira/browse/HIVE-28297
> Project: Hive
> Issue Type: Improvement
> Components: Hive
>Reporter: Wechar
>Assignee: Wechar
>Priority: Major
>
> *Current Situation*
> There are two cases for table pattern in Hive:
> - Case 1: Wildcards ('*' and '|)
> It's replaced by SQL type like expressions with '%' and '_' since Hive 4.0.0,
> details in HIVE-23359.
> DDL documents:
> https://cwiki.apache.org/confluence/display/Hive/LanguageManual+DDL#LanguageManualDDL-Show
> - Case 2: Java regular expression
> It's declared in hive code:
> [https://github.com/apache/hive/blob/45867be6cb5308566e4cf16c7b4cf8081085b58c/ql/src/java/org/apache/hadoop/hive/ql/metadata/Hive.java#L1882-L1894],
> and also match the jdo {{matches(String pattern)}} method:
> [https://www.datanucleus.org/products/accessplatform/jdo/query.html]
> *Issues*
> The different definitions cause the misuse of table pattern, in some codes it
> use * to represent match everything, while it use .* in other codes.
> The misuse would cause the wrong result because both client and server side
> of HMS need a trick handle for '*' with code like:
> {code:java}
> patterns.split("\\|")
> pattern.replaceAll("\\*", ".*"))
> {code}
> *Action*
> We should honor the definition in HMS of Case 2, because Case 1 is just the
> frontend of SQL, and it has been replaced.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (HIVE-28297) Unify table pattern definition in Hive MetaStore
Wechar created HIVE-28297:
-
Summary: Unify table pattern definition in Hive MetaStore
Key: HIVE-28297
URL: https://issues.apache.org/jira/browse/HIVE-28297
Project: Hive
Issue Type: Improvement
Components: Hive
Reporter: Wechar
Assignee: Wechar
*Current Situation*
There are two cases for table pattern in Hive:
- Case 1: Wildcards ('*' and '|)
It's replaced by SQL type like expressions with '%' and '_' since Hive 4.0.0,
details in HIVE-23359
- Case 2: Java regular expression
It's declared in hive code:
[https://github.com/apache/hive/blob/45867be6cb5308566e4cf16c7b4cf8081085b58c/ql/src/java/org/apache/hadoop/hive/ql/metadata/Hive.java#L1882-L1894],
and also match the jdo {{matches(String pattern)}} method:
[https://www.datanucleus.org/products/accessplatform/jdo/query.html]
*Issues*
The different definitions cause the misuse of table pattern, in some codes it
use * to represent match everything, while it use .* in other codes.
The misuse would cause the wrong result because both client and server side of
HMS need a trick handle for '*' with code like:
{code:java}
patterns.split("\\|")
pattern.replaceAll("\\*", ".*"))
{code}
*Action*
We should honor the definition in HMS of Case 2, because Case 1 is just the
frontend of SQL, and it has been replaced.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (HIVE-28181) Hive query plans display is disabled by default
[ https://issues.apache.org/jira/browse/HIVE-28181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] asish kumar patra reassigned HIVE-28181: Assignee: asish kumar patra > Hive query plans display is disabled by default > --- > > Key: HIVE-28181 > URL: https://issues.apache.org/jira/browse/HIVE-28181 > Project: Hive > Issue Type: Sub-task > Environment: When value of Hive config > 'hive.server2.webui.explain.output' is false, query plan showing is disabled > in Hive UI. The default value is 'false'. >Reporter: Dmitriy Fingerman >Assignee: asish kumar patra >Priority: Major > Attachments: Screen Shot 2024-04-05 at 5.18.10 PM.png > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (HIVE-28181) Hive query plans display is disabled by default
[ https://issues.apache.org/jira/browse/HIVE-28181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] asish kumar patra reassigned HIVE-28181: Assignee: asish kumar patra > Hive query plans display is disabled by default > --- > > Key: HIVE-28181 > URL: https://issues.apache.org/jira/browse/HIVE-28181 > Project: Hive > Issue Type: Sub-task > Environment: When value of Hive config > 'hive.server2.webui.explain.output' is false, query plan showing is disabled > in Hive UI. The default value is 'false'. >Reporter: Dmitriy Fingerman >Assignee: asish kumar patra >Priority: Major > Attachments: Screen Shot 2024-04-05 at 5.18.10 PM.png > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (HIVE-28181) Hive query plans display is disabled by default
[ https://issues.apache.org/jira/browse/HIVE-28181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] asish kumar patra reassigned HIVE-28181: Assignee: (was: asish kumar patra) > Hive query plans display is disabled by default > --- > > Key: HIVE-28181 > URL: https://issues.apache.org/jira/browse/HIVE-28181 > Project: Hive > Issue Type: Sub-task > Environment: When value of Hive config > 'hive.server2.webui.explain.output' is false, query plan showing is disabled > in Hive UI. The default value is 'false'. >Reporter: Dmitriy Fingerman >Priority: Major > Attachments: Screen Shot 2024-04-05 at 5.18.10 PM.png > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (HIVE-28276) Iceberg: Make Iceberg split threads configurable when table scanning
[ https://issues.apache.org/jira/browse/HIVE-28276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17851691#comment-17851691 ] Denys Kuzmenko commented on HIVE-28276: --- Merged to master [~zhangbutao] thanks for the patch and [~ayushsaxena] for the review! > Iceberg: Make Iceberg split threads configurable when table scanning > > > Key: HIVE-28276 > URL: https://issues.apache.org/jira/browse/HIVE-28276 > Project: Hive > Issue Type: Improvement > Components: Iceberg integration >Reporter: Butao Zhang >Assignee: Butao Zhang >Priority: Major > Labels: pull-request-available > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (HIVE-28276) Iceberg: Make Iceberg split threads configurable when table scanning
[ https://issues.apache.org/jira/browse/HIVE-28276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denys Kuzmenko resolved HIVE-28276. --- Fix Version/s: 4.1.0 Resolution: Fixed > Iceberg: Make Iceberg split threads configurable when table scanning > > > Key: HIVE-28276 > URL: https://issues.apache.org/jira/browse/HIVE-28276 > Project: Hive > Issue Type: Improvement > Components: Iceberg integration >Reporter: Butao Zhang >Assignee: Butao Zhang >Priority: Major > Labels: pull-request-available > Fix For: 4.1.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (HIVE-28296) TestGracefulStopHS2 to run on Tez
László Bodor created HIVE-28296: --- Summary: TestGracefulStopHS2 to run on Tez Key: HIVE-28296 URL: https://issues.apache.org/jira/browse/HIVE-28296 Project: Hive Issue Type: Sub-task Reporter: László Bodor -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (HIVE-28254) CBO (Calcite Return Path): Multiple DISTINCT leads to wrong results
[
https://issues.apache.org/jira/browse/HIVE-28254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Krisztian Kasa updated HIVE-28254:
--
Parent: HIVE-9132
Issue Type: Sub-task (was: Bug)
> CBO (Calcite Return Path): Multiple DISTINCT leads to wrong results
> ---
>
> Key: HIVE-28254
> URL: https://issues.apache.org/jira/browse/HIVE-28254
> Project: Hive
> Issue Type: Sub-task
> Components: CBO
>Affects Versions: 4.0.0
>Reporter: Shohei Okumiya
>Assignee: Shohei Okumiya
>Priority: Major
> Labels: hive-4.0.1-must, pull-request-available
>
> CBO return path can build incorrect GroupByOperator when multiple
> aggregations with DISTINCT are involved.
> This is an example.
> {code:java}
> CREATE TABLE test (col1 INT, col2 INT);
> INSERT INTO test VALUES (1, 100), (2, 200), (2, 200), (3, 300);
> set hive.cbo.returnpath.hiveop=true;
> set hive.map.aggr=false;
> SELECT
> SUM(DISTINCT col1),
> COUNT(DISTINCT col1),
> SUM(DISTINCT col2),
> SUM(col2)
> FROM test;{code}
> The last column should be 800. But the SUM refers to col1 and the actual
> result is 8.
> {code:java}
> +--+--+--+--+
> | _c0 | _c1 | _c2 | _c3 |
> +--+--+--+--+
> | 6 | 3 | 600 | 8 |
> +--+--+--+--+ {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (HIVE-28285) Exception when querying JDBC tables with Hive/DB column types mismatch
[
https://issues.apache.org/jira/browse/HIVE-28285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stamatis Zampetakis resolved HIVE-28285.
Fix Version/s: 4.1.0
Resolution: Fixed
Fixed in
[https://github.com/apache/hive/commit/07cc9c3faebf790284ed0b3b2811f83394575ff5]
Thanks for the review [~dengzh] !
> Exception when querying JDBC tables with Hive/DB column types mismatch
> --
>
> Key: HIVE-28285
> URL: https://issues.apache.org/jira/browse/HIVE-28285
> Project: Hive
> Issue Type: Bug
> Components: HiveServer2
>Affects Versions: 4.0.0
>Reporter: Stamatis Zampetakis
>Assignee: Stamatis Zampetakis
>Priority: Major
> Labels: pull-request-available
> Fix For: 4.1.0
>
>
> Queries over JDBC tables fail at runtime when the following conditions hold:
> # there is a mismatch between the Hive type and the database type for some
> columns
> # CBO is not used
> CBO may not be used when compiling the query for various reasons:
> * CBO is explicitly disabled (via hive.cbo.enable property)
> * Query explicitly not supported in CBO (e.g., contains DISTRIBUTE BY clause)
> * Problem/bug in compilation that will skip CBO execution
> The examples below demonstrate the problem with Postgres but the problem
> itself is not database specific (although different errors may pop up
> depending on the underlying database). Different type mappings may also lead
> to different errors.
> h3. Map Postgres DATE to Hive TIMESTAMP
> +Postgres+
> {code:sql}
> create table date_table (cdate date);
> insert into date_table values ('2024-05-29');
> {code}
> +Hive+
> {code:sql}
> CREATE TABLE h_type_table (cdate timestamp)
> STORED BY 'org.apache.hive.storage.jdbc.JdbcStorageHandler'
> TBLPROPERTIES (
> "hive.sql.database.type" = "POSTGRES",
> "hive.sql.jdbc.driver" = "org.postgresql.Driver",
> "hive.sql.jdbc.url" = "jdbc:postgresql://...",
> "hive.sql.dbcp.username" = "user",
> "hive.sql.dbcp.password" = "pwd",
> "hive.sql.table" = "date_table"
> );
> {code}
> +Hive Result (CBO on)+
> |2024-05-29 00:00:00|
> +Error (CBO off)+
> {noformat}
> java.lang.RuntimeException: java.io.IOException:
> java.lang.IllegalArgumentException: Cannot create timestamp, parsing error
> 2024-05-29
> at
> org.apache.hadoop.hive.ql.exec.FetchTask.executeInner(FetchTask.java:210)
> at org.apache.hadoop.hive.ql.exec.FetchTask.execute(FetchTask.java:95)
> at org.apache.hadoop.hive.ql.Driver.runInternal(Driver.java:212)
> at org.apache.hadoop.hive.ql.Driver.run(Driver.java:154)
> at org.apache.hadoop.hive.ql.Driver.run(Driver.java:149)
> at
> org.apache.hadoop.hive.ql.reexec.ReExecDriver.run(ReExecDriver.java:185)
> at
> org.apache.hadoop.hive.ql.reexec.ReExecDriver.run(ReExecDriver.java:230)
> at
> org.apache.hadoop.hive.cli.CliDriver.processLocalCmd(CliDriver.java:257)
> at org.apache.hadoop.hive.cli.CliDriver.processCmd1(CliDriver.java:201)
> at org.apache.hadoop.hive.cli.CliDriver.processCmd(CliDriver.java:127)
> at org.apache.hadoop.hive.cli.CliDriver.processLine(CliDriver.java:425)
> at org.apache.hadoop.hive.cli.CliDriver.processLine(CliDriver.java:356)
> at
> org.apache.hadoop.hive.ql.QTestUtil.executeClientInternal(QTestUtil.java:732)
> at org.apache.hadoop.hive.ql.QTestUtil.executeClient(QTestUtil.java:702)
> at
> org.apache.hadoop.hive.cli.control.CoreCliDriver.runTest(CoreCliDriver.java:116)
> at
> org.apache.hadoop.hive.cli.control.CliAdapter.runTest(CliAdapter.java:157)
> at
> org.apache.hadoop.hive.cli.TestMiniLlapLocalCliDriver.testCliDriver(TestMiniLlapLocalCliDriver.java:62)
> Caused by: java.io.IOException: java.lang.IllegalArgumentException: Cannot
> create timestamp, parsing error 2024-05-29
> at
> org.apache.hadoop.hive.ql.exec.FetchOperator.getNextRow(FetchOperator.java:628)
> at
> org.apache.hadoop.hive.ql.exec.FetchOperator.pushRow(FetchOperator.java:535)
> at
> org.apache.hadoop.hive.ql.exec.FetchTask.executeInner(FetchTask.java:194)
> ... 55 more
> Caused by: java.lang.IllegalArgumentException: Cannot create timestamp,
> parsing error 2024-05-29
> at
> org.apache.hadoop.hive.common.type.Timestamp.valueOf(Timestamp.java:194)
> at
> org.apache.hive.storage.jdbc.JdbcSerDe.deserialize(JdbcSerDe.java:314)
> at
> org.apache.hadoop.hive.ql.exec.FetchOperator.getNextRow(FetchOperator.java:609)
> ... 57 more
> Caused by: java.time.format.DateTimeParseException: Text '2024-05-29' could
> not be parsed: Unable to obtain LocalDateTime from TemporalAccessor: {},ISO
> resolved to 2024-05-29 of type java.time.format.Parsed
> at
> java.time.format.DateTimeFormatter.createE
[jira] [Comment Edited] (HIVE-28293) TestGracefulStopHS2 runs too long
[
https://issues.apache.org/jira/browse/HIVE-28293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17851550#comment-17851550
]
Zhihua Deng edited comment on HIVE-28293 at 6/3/24 8:18 AM:
Sounds like the query is still running on cancellation until it completes(Tez)
in this case, or could we remove this line?
[https://github.com/apache/hive/blob/8c90ec0ce576d6319470f7dc4dd27daebb654dec/ql/src/java/org/apache/hadoop/hive/ql/exec/tez/TezTask.java#L420]
was (Author: dengzh):
Sounds like the query is still running on cancellation until it completes(Tez)
in this case, or could we remove this line?
[https://github.com/apache/hive/blob/8c90ec0ce576d6319470f7dc4dd27daebb654dec/ql/src/java/org/apache/hadoop/hive/ql/exec/tez/TezTask.java#L420]
> TestGracefulStopHS2 runs too long
> -
>
> Key: HIVE-28293
> URL: https://issues.apache.org/jira/browse/HIVE-28293
> Project: Hive
> Issue Type: Bug
>Reporter: László Bodor
>Assignee: Zhihua Deng
>Priority: Major
> Labels: newbie
>
> it tests whether long queries are finished successfully in the event of a
> graceful shutdown, however 10 minutes seems to be too long:
> https://github.com/apache/hive/blob/8c90ec0ce576d6319470f7dc4dd27daebb654dec/itests/hive-unit/src/test/java/org/apache/hive/service/server/TestGracefulStopHS2.java#L85
> I'm pretty sure we can validate this in a few minutes
> {code}
> [INFO] ---
> [INFO] T E S T S
> [INFO] ---
> [INFO] Running org.apache.hive.service.server.TestGracefulStopHS2
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 1,225.833 s - in org.apache.hive.service.server.TestGracefulStopHS2
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (HIVE-28293) TestGracefulStopHS2 runs too long
[
https://issues.apache.org/jira/browse/HIVE-28293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17851550#comment-17851550
]
Zhihua Deng commented on HIVE-28293:
Sounds like the query is still running on cancellation until it completes(Tez)
in this case, or could we remove this line?
[https://github.com/apache/hive/blob/8c90ec0ce576d6319470f7dc4dd27daebb654dec/ql/src/java/org/apache/hadoop/hive/ql/exec/tez/TezTask.java#L420]
> TestGracefulStopHS2 runs too long
> -
>
> Key: HIVE-28293
> URL: https://issues.apache.org/jira/browse/HIVE-28293
> Project: Hive
> Issue Type: Bug
>Reporter: László Bodor
>Assignee: Zhihua Deng
>Priority: Major
> Labels: newbie
>
> it tests whether long queries are finished successfully in the event of a
> graceful shutdown, however 10 minutes seems to be too long:
> https://github.com/apache/hive/blob/8c90ec0ce576d6319470f7dc4dd27daebb654dec/itests/hive-unit/src/test/java/org/apache/hive/service/server/TestGracefulStopHS2.java#L85
> I'm pretty sure we can validate this in a few minutes
> {code}
> [INFO] ---
> [INFO] T E S T S
> [INFO] ---
> [INFO] Running org.apache.hive.service.server.TestGracefulStopHS2
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 1,225.833 s - in org.apache.hive.service.server.TestGracefulStopHS2
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
