hive-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hive QA (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HIVE-19847) Create Separate getInputSummary Service
Date Tue, 12 Jun 2018 11:19:00 GMT

    [ https://issues.apache.org/jira/browse/HIVE-19847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16509505#comment-16509505
] 

Hive QA commented on HIVE-19847:
--------------------------------



Here are the results of testing the latest attachment:
https://issues.apache.org/jira/secure/attachment/12927341/HIVE-19847.2.patch

{color:green}SUCCESS:{color} +1 due to 2 test(s) being added or modified.

{color:red}ERROR:{color} -1 due to 12 failed/errored test(s), 14519 tests executed
*Failed tests:*
{noformat}
org.apache.hadoop.hive.ql.stats.TestStatsUpdaterThread.testQueueingWithThreads (batchId=277)
org.apache.hive.jdbc.TestTriggersTezSessionPoolManager.testTriggerHighBytesWrite (batchId=246)
org.apache.hive.jdbc.TestTriggersWorkloadManager.testMultipleTriggers2 (batchId=243)
org.apache.hive.jdbc.TestTriggersWorkloadManager.testTriggerCustomCreatedDynamicPartitions
(batchId=243)
org.apache.hive.jdbc.TestTriggersWorkloadManager.testTriggerCustomCreatedDynamicPartitionsMultiInsert
(batchId=243)
org.apache.hive.jdbc.TestTriggersWorkloadManager.testTriggerCustomCreatedDynamicPartitionsUnionAll
(batchId=243)
org.apache.hive.jdbc.TestTriggersWorkloadManager.testTriggerCustomCreatedFiles (batchId=243)
org.apache.hive.jdbc.TestTriggersWorkloadManager.testTriggerCustomNonExistent (batchId=243)
org.apache.hive.jdbc.TestTriggersWorkloadManager.testTriggerCustomReadOps (batchId=243)
org.apache.hive.jdbc.TestTriggersWorkloadManager.testTriggerHighBytesRead (batchId=243)
org.apache.hive.jdbc.TestTriggersWorkloadManager.testTriggerHighShuffleBytes (batchId=243)
org.apache.hive.jdbc.TestTriggersWorkloadManager.testTriggerVertexRawInputSplitsNoKill (batchId=243)
{noformat}

Test results: https://builds.apache.org/job/PreCommit-HIVE-Build/11727/testReport
Console output: https://builds.apache.org/job/PreCommit-HIVE-Build/11727/console
Test logs: http://104.198.109.242/logs/PreCommit-HIVE-Build-11727/

Messages:
{noformat}
Executing org.apache.hive.ptest.execution.TestCheckPhase
Executing org.apache.hive.ptest.execution.PrepPhase
Executing org.apache.hive.ptest.execution.YetusPhase
Executing org.apache.hive.ptest.execution.ExecutionPhase
Executing org.apache.hive.ptest.execution.ReportingPhase
Tests exited with: TestsFailedException: 12 tests failed
{noformat}

This message is automatically generated.

ATTACHMENT ID: 12927341 - PreCommit-HIVE-Build

> Create Separate getInputSummary Service
> ---------------------------------------
>
>                 Key: HIVE-19847
>                 URL: https://issues.apache.org/jira/browse/HIVE-19847
>             Project: Hive
>          Issue Type: Improvement
>          Components: HiveServer2
>    Affects Versions: 3.0.0, 4.0.0
>            Reporter: BELUGA BEHR
>            Assignee: BELUGA BEHR
>            Priority: Major
>         Attachments: HIVE-19847.1.patch, HIVE-19847.2.patch
>
>
> The Hive {{org.apache.hadoop.hive.ql.exec.Utilities.java}} file has taken on a life of
its own.  We should consider separating out the various components into their own classes.
 For this ticket, I propose separating out the {{getInputSummary}} functionality into its
own class.
> There are several issues with the current implementation:
> # It is [synchronized|https://github.com/apache/hive/blob/f27c38ff55902827499192a4f8cf8ed37d6fd967/ql/src/java/org/apache/hadoop/hive/ql/exec/Utilities.java#L2383].
 Only one query can get file input summary at a time.  For a query which deals with a large
data set with a large number of files, this can block other queries for a long period of time.
 This is especially painful when most queries use a small data set, but a large data set is
submitted on occasion.
> # For each query, time is spend setting up and tearing down a ThreadPool
> # It uses deprecated code
> I propose breaking it out into its own class and creating a single thread pool that all
queries pull from.  In this way, the bottle neck will be one the number of available threads,
not on a single query and if a big query is running and a small query is also submitted, the
smaller query will be able to proceed.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Mime
View raw message