Mailing-List: contact dev-help@ambari.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ambari.apache.org
Date: Thu, 14 Jan 2016 11:50:39 +0000 (UTC)
From: "Sandor Magyari (JIRA)" <jira@apache.org>
To: dev@ambari.apache.org
Message-ID: <JIRA.12930117.1452772216000.108977.1452772239779@Atlassian.JIRA>
In-Reply-To: <JIRA.12930117.1452772216000@Atlassian.JIRA>
References: <JIRA.12930117.1452772216000@Atlassian.JIRA>
 <JIRA.12930117.1452772216529@arcas>
Subject: [jira] [Created] (AMBARI-14665) Race condition problem in
 ServiceComponentHostImpl when provisioning cluster with Blueprint
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Sandor Magyari created AMBARI-14665:
---------------------------------------

             Summary: Race condition problem in ServiceComponentHostImpl when provisioning cluster with Blueprint
                 Key: AMBARI-14665
                 URL: https://issues.apache.org/jira/browse/AMBARI-14665
             Project: Ambari
          Issue Type: Bug
    Affects Versions: 2.2.0
            Reporter: Sandor Magyari
            Assignee: Sandor Magyari
             Fix For: 2.2.1


Sometimes when provisioning cluster with Blueprint, there are state inconsistencies between state and desired_state of components on a given host. Usually desired_state is still INSTALLED while state is STARTED.

Analyzing the logs of affected components, the problem seems to be a race condition in ServiceComponentHostImpl. This is modified by ActionScheduler, HeartBeatMonitor and HostComponentResourceProvider as well which is used when creating INSTALL and START tasks, modifying desired states.
ServiceComponentHostImpl state is stored in two entities: HostComponentStateEntity, HostComponentDesiredStateEntity. Regardless of changes made both entities are merged back to db but only one is fetched from db before merge.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)