incubator-cloudstack-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF subversion and git services (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CLOUDSTACK-1522) File lock mechanism cannot get correct order when two process want to get the lock in the same second
Date Wed, 06 Mar 2013 00:00:13 GMT

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

ASF subversion and git services commented on CLOUDSTACK-1522:
-------------------------------------------------------------

Commit dd721a832a408385d126975d7ab7d76b03ad8414 in branch refs/heads/master from Sheng Yang
<sheng.yang@citrix.com>
[ https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;h=dd721a8 ]

CLOUDSTACK-1522: Add timestamp to lock

Use higher precision timestamp rather than file timestamp to find out the order
of lock requester

                
> File lock mechanism cannot get correct order when two process want to get the lock in
the same second
> -----------------------------------------------------------------------------------------------------
>
>                 Key: CLOUDSTACK-1522
>                 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1522
>             Project: CloudStack
>          Issue Type: Bug
>      Security Level: Public(Anyone can view this level - this is the default.) 
>    Affects Versions: 4.0.0, 4.1.0
>            Reporter: Sheng Yang
>            Assignee: Sheng Yang
>            Priority: Critical
>             Fix For: 4.2.0
>
>
> The file lock mechanism is trying to provide a function that the lock requester would
get the lock in the order they requested. This is implemented by using lock file's timestamp.

> But in ext3, timestamp's precision is only in seconds, so when two requester want to
get the same lock in the same second, the order cannot be guaranteed. 
> This caused issue in redundant router, when keepalived detected MASTER disappear then
soon MASTER back again, keepalived would call switch to MASTER script first, then immediately
call switch to BACKUP script, which may result in BACKUP script is called before MASTER script,
since they're executed in the same second.
> File lock need to get high precision for determining the order of requester.

--
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

Mime
View raw message