Mailing-List: contact issues-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cloudstack.apache.org
Date: Tue, 2 Apr 2013 18:25:18 +0000 (UTC)
From: "Chiradeep Vittal (JIRA)" <jira@apache.org>
To: cloudstack-issues@incubator.apache.org
Message-ID: <JIRA.12640348.1364926311253.93345.1364927118742@arcas>
In-Reply-To: <JIRA.12640348.1364926311253@arcas>
References: <JIRA.12640348.1364926311253@arcas>
Subject: [jira] [Updated] (CLOUDSTACK-1896) S3-backed NFS secondary storage
 uses Db-based lock when DB is not available
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/CLOUDSTACK-1896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Chiradeep Vittal updated CLOUDSTACK-1896:
-----------------------------------------

    Description: 
While perusing NfsSecondaryStorageResource.java, I came across:
 public Answer execute(final DownloadSnapshotFromS3Command cmd) {
       ...
        try {

            executeWithNoWaitLock(determineSnapshotLockId(accountId, volumeId),
                    new Callable<Void>() {

                @Override
                public Void call() throws Exception {
                ....
                }
       }

The executeWithNoWaitLock utility uses the management server database, which is not available inside the secondary storage vm. So, my conclusion is that there is no way this code works.

This also affects the method deleteSnapshotBackupfromS3

  was:
While perusing NfsSecondaryStorageResource.java, I came across:
 public Answer execute(final DownloadSnapshotFromS3Command cmd) {
       ...
        try {

            executeWithNoWaitLock(determineSnapshotLockId(accountId, volumeId),
                    new Callable<Void>() {

                @Override
                public Void call() throws Exception {
                ....
                }
       }

The executeWithNoWaitLock utility uses the management server database, which is not available inside the secondary storage vm. So, my conclusion is that there is no way this code works.

Unfortunately the same code has been added to the Swift-backed code as well and will therefore break that as well.

        Summary: S3-backed NFS secondary storage uses Db-based lock when DB is not available  (was: S3 and Swift-backed NFS secondary storage uses Db-based lock when DB is not available)
    
> S3-backed NFS secondary storage uses Db-based lock when DB is not available
> ---------------------------------------------------------------------------
>
>                 Key: CLOUDSTACK-1896
>                 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1896
>             Project: CloudStack
>          Issue Type: Bug
>      Security Level: Public(Anyone can view this level - this is the default.) 
>          Components: Storage Controller
>    Affects Versions: 4.1.0, 4.2.0
>            Reporter: Chiradeep Vittal
>            Assignee: John Burwell
>
> While perusing NfsSecondaryStorageResource.java, I came across:
>  public Answer execute(final DownloadSnapshotFromS3Command cmd) {
>        ...
>         try {
>             executeWithNoWaitLock(determineSnapshotLockId(accountId, volumeId),
>                     new Callable<Void>() {
>                 @Override
>                 public Void call() throws Exception {
>                 ....
>                 }
>        }
> The executeWithNoWaitLock utility uses the management server database, which is not available inside the secondary storage vm. So, my conclusion is that there is no way this code works.
> This also affects the method deleteSnapshotBackupfromS3

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira