Return-Path: X-Original-To: apmail-cloudstack-issues-archive@www.apache.org Delivered-To: apmail-cloudstack-issues-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 3698D19CC5 for ; Wed, 13 Apr 2016 02:42:26 +0000 (UTC) Received: (qmail 2334 invoked by uid 500); 13 Apr 2016 02:42:26 -0000 Delivered-To: apmail-cloudstack-issues-archive@cloudstack.apache.org Received: (qmail 2217 invoked by uid 500); 13 Apr 2016 02:42:26 -0000 Mailing-List: contact issues-help@cloudstack.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cloudstack.apache.org Delivered-To: mailing list issues@cloudstack.apache.org Received: (qmail 2199 invoked by uid 500); 13 Apr 2016 02:42:25 -0000 Delivered-To: apmail-incubator-cloudstack-issues@incubator.apache.org Received: (qmail 2187 invoked by uid 99); 13 Apr 2016 02:42:25 -0000 Received: from arcas.apache.org (HELO arcas) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 13 Apr 2016 02:42:25 +0000 Received: from arcas.apache.org (localhost [127.0.0.1]) by arcas (Postfix) with ESMTP id BE3BC2C1F5A for ; Wed, 13 Apr 2016 02:42:25 +0000 (UTC) Date: Wed, 13 Apr 2016 02:42:25 +0000 (UTC) From: "Pierre-Luc Dion (JIRA)" To: cloudstack-issues@incubator.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Updated] (CLOUDSTACK-9180) Optimize concurrent VM deployment operation on same network MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/CLOUDSTACK-9180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre-Luc Dion updated CLOUDSTACK-9180: ---------------------------------------- Fix Version/s: (was: 4.7.0) Future > Optimize concurrent VM deployment operation on same network > ----------------------------------------------------------- > > Key: CLOUDSTACK-9180 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9180 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the default.) > Components: Management Server > Affects Versions: 4.6.0 > Reporter: Koushik Das > Assignee: Koushik Das > Fix For: Future > > > During VM deployment a check is performed to see if VR exists or not. If not it is created - first an entry is allocated in DB for VR and then it is deployed. The allocation logic is placed in a lock (based on network id) so that only one thread does the allocation. But the locking is implemented in a way such that all threads wait on that lock even when VR is already allocated. The correct approach would be to check if VR is allocated or not and acquire lock only when needed. > This issue is more frequently seen when concurrently deploying VMs in basic zone as all threads try to acquire lock using the same network id. In advanced zone operations are spread across multiple networks and so less frequent. > Refer to findOrDeployVirtualRouter() in RouterDeploymentDefinition.java. -- This message was sent by Atlassian JIRA (v6.3.4#6332)