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