jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexander Klimetschek (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JCR-1605) RepositoryLock does not work on NFS sometimes
Date Mon, 19 May 2008 09:59:55 GMT

    [ https://issues.apache.org/jira/browse/JCR-1605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12597907#action_12597907
] 

Alexander Klimetschek commented on JCR-1605:
--------------------------------------------

> The message "No locks available" sounds like there is a number of locks, and if more
locks are used this exception occurs.

No, this error message meant that the file system does not provide the file locking feature
at all. An NFS 2 or 3 was used which don't have the feature at all. Only NFS 4 allows locking.
But it's not recommended to rely on it.

Anyway, I would also be against an automatic mix of lock algorithms. For example, current
file locking might work perfectly on the NFS server, since it accesses the local file system
directly, which will most probably provide file locking. Another jackrabbit running as an
NFS (2/3) client, accessing the same repository directory, would get an exception "No locks
available". If it would continue with another algorithm, it will not see the repository as
locked and start it.

> RepositoryLock does not work on NFS sometimes
> ---------------------------------------------
>
>                 Key: JCR-1605
>                 URL: https://issues.apache.org/jira/browse/JCR-1605
>             Project: Jackrabbit
>          Issue Type: Bug
>            Reporter: Thomas Mueller
>            Assignee: Thomas Mueller
>
> The RepositoryLock mechanism currently used in Jackrabbit uses FileLock. This doesn't
work on some NFS file system. It looks like only NFS version 4 and newer supports locking.
Older implementations may throw a IOException "No locks available", which means the NFS does
not support byte-range locking.
> I propose to add a second locking mechanism, and add a configuration option to use it.
For example: <FileLocking class="acme" />. This second locking mechanism is a cooperative
locking protocol that uses a background (watchdog) thread and only uses regular file operations.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message