ambari-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hadoop QA (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (AMBARI-20712) Parallel Requests With Intersecting Hosts Don't Block Correctly
Date Sun, 09 Apr 2017 01:46:41 GMT

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

Hadoop QA commented on AMBARI-20712:
------------------------------------

{color:red}-1 overall{color}.  Here are the results of testing the latest attachment 
  http://issues.apache.org/jira/secure/attachment/12862600/AMBARI-20712.patch
  against trunk revision .

    {color:red}-1 patch{color}.  The patch command could not apply the patch.

Console output: https://builds.apache.org/job/Ambari-trunk-test-patch/11335//console

This message is automatically generated.

> Parallel Requests With Intersecting Hosts Don't Block Correctly
> ---------------------------------------------------------------
>
>                 Key: AMBARI-20712
>                 URL: https://issues.apache.org/jira/browse/AMBARI-20712
>             Project: Ambari
>          Issue Type: Bug
>    Affects Versions: 2.5.1
>            Reporter: Jonathan Hurley
>            Assignee: Jonathan Hurley
>            Priority: Blocker
>             Fix For: 2.5.1
>
>         Attachments: AMBARI-20712.patch
>
>
> AMBARI-20646 introduced a regression which can be seen when deploying a cluster via blueprint
with Kerberization. The problem is caused by the change which was made to only pull in the
most recent stage in progress per request.
> There was logic which prevented concurrently executing request stages to be scheduled
if a prior request had an un-executed stage with a conflicting host. For example:
> - Request 1
> -- Stage 1 (IN_PROGRESS)
> --- Host 1
> --- Host 2
> --- Host 3
> -- Stage 2 (PENDING)
> --- Host 4
> - Request 2
> -- Stage 1
> --- Host 4
> In the above scenario, the scheduler was tricked into thinking that Request 2 can run
even though Host-4 has a conflict. This is because it was only looking at the stage in progress.
> We can't simply look at all stages in progress since this would cause the performance
bug to manifest again. So, the solution is to have the database tell us which hosts are blocking
from prior requests. This SQL should be very fast and will only run in the specific cases
where there are multiple concurrent requests (which is typically at blueprint time).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Mime
View raw message