[
https://issues.apache.org/jira/browse/HIVE-24201?focusedWorklogId=570655&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-570655
]
ASF GitHub Bot logged work on HIVE-24201:
-----------------------------------------
Author: ASF GitHub Bot
Created on: 23/Mar/21 17:15
Start Date: 23/Mar/21 17:15
Worklog Time Spent: 10m
Work Description: Dawn2111 commented on a change in pull request #2065:
URL: https://github.com/apache/hive/pull/2065#discussion_r599773480
##########
File path: ql/src/java/org/apache/hadoop/hive/ql/exec/tez/WorkloadManager.java
##########
@@ -794,17 +828,17 @@ private void handleMoveSessionOnMasterThread(final
MoveSession moveSession,
final WmThreadSyncWork syncWork,
final HashSet<String> poolsToRedistribute,
final Map<WmTezSession, GetRequest> toReuse,
- final Map<WmTezSession, WmEvent> recordMoveEvents) {
+ final Map<WmTezSession, WmEvent> recordMoveEvents, final boolean
moveImmediately) {
String destPoolName = moveSession.destPool;
- LOG.info("Handling move session event: {}", moveSession);
+ LOG.info("Handling move session event: {}, move immediately: {}",
moveSession, moveImmediately);
if (validMove(moveSession.srcSession, destPoolName)) {
WmEvent moveEvent = new WmEvent(WmEvent.EventType.MOVE);
- // remove from src pool
- RemoveSessionResult rr = checkAndRemoveSessionFromItsPool(
+ // check if there is capacity in dest pool
+ if (capacityAvailable(destPoolName)) {
Review comment:
Thanks for catch! This introduced a bug as the session wasn't being
removed from the source pool when the query was killed. However, cannot do
exactly as suggested above as we don't want to remove the session from the
source pool if delayedMove is true and dest pool is maxed out. Changed it like
this :
Left the flow as it is if delayedMove is false. Added a block for the case
when delayed move is true and dest. pool is maxed out. This adds the session to
the source pool's delayedMoveSessions.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
Issue Time Tracking
-------------------
Worklog Id: (was: 570655)
Time Spent: 1h 10m (was: 1h)
> WorkloadManager kills query being moved to different pool if destination pool
> does not have enough sessions
> -----------------------------------------------------------------------------------------------------------
>
> Key: HIVE-24201
> URL: https://issues.apache.org/jira/browse/HIVE-24201
> Project: Hive
> Issue Type: Improvement
> Components: HiveServer2, llap
> Affects Versions: 4.0.0
> Reporter: Adesh Kumar Rao
> Assignee: Pritha Dawn
> Priority: Minor
> Labels: pull-request-available
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> To reproduce, create a resource plan with move trigger, like below:
> {code:java}
> +----------------------------------------------------+
> | line |
> +----------------------------------------------------+
> | experiment[status=DISABLED,parallelism=null,defaultPool=default] |
> | + default[allocFraction=0.888,schedulingPolicy=null,parallelism=1] |
> | | mapped for default |
> | + pool2[allocFraction=0.1,schedulingPolicy=fair,parallelism=1] |
> | | trigger t1: if (ELAPSED_TIME > 20) { MOVE TO pool1 } |
> | | mapped for users: abcd |
> | + pool1[allocFraction=0.012,schedulingPolicy=null,parallelism=1] |
> | | mapped for users: efgh |
>
> {code}
> Now, run two queries in pool1 and pool2 using different users. The query
> running in pool2 will tried to move to pool1 and it will get killed because
> pool1 will not have session to handle the query.
> Currently, the Workload management move trigger kills the query being moved
> to a different pool if destination pool does not have enough capacity. We
> could have a "delayed move" configuration which lets the query run in the
> source pool as long as possible, if the destination pool is full. It will
> attempt the move to destination pool only when there is claim upon the source
> pool. If the destination pool is not full, delayed move behaves as normal
> move i.e. the move will happen immediately.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
