[
https://issues.apache.org/jira/browse/CLOUDSTACK-9180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15288699#comment-15288699
]
ASF GitHub Bot commented on CLOUDSTACK-9180:
--------------------------------------------
GitHub user koushik-das reopened a pull request:
https://github.com/apache/cloudstack/pull/1251
CLOUDSTACK-9180: Optimize concurrent VM deployment operation on same …
…network
Check if VR needs to be allocated for a given network and only acquire lock
if required
Refer to the bug for details.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/koushik-das/cloudstack CLOUDSTACK-9180
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/cloudstack/pull/1251.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #1251
----
commit de8942644df26fdd97010f8eec1fddf7d97fc8ae
Author: Koushik Das <[email protected]>
Date: 2015-12-16T12:23:03Z
CLOUDSTACK-9180: Optimize concurrent VM deployment operation on same network
Check if VR needs to be allocated for a given network and only acquire lock
if required
----
> 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)
