Uploaded image for project: 'Jackrabbit Content Repository'
  1. Jackrabbit Content Repository
  2. JCR-3977

New cluster node resets timeout of the open-scoped lock

    XMLWordPrintableJSON

Details

    • Bug
    • Status: Open
    • Major
    • Resolution: Unresolved
    • 2.11.3
    • None
    • JCR 2.0
    • None

    Description

      Problem

      Suppose we have an active open-scoped lock with a timeout set to 5 minutes (the time to wait before the lock gets automatically released). Such a lock would be present in the data store, e.g. Oracle DBMS, in the following format (for instance, judging from the content of the persisted BLOB):

      0899d423-c9e4-4d9b-a46e-a5055df8a23c-2,300
      

      Consider that before the lock is unlocked, a new org.apache.jackrabbit.core.cluster.ClusterNode joins the cluster. When synchronization takes places for the new member of the cluster, the timeout of the existing lock gets updated to the Long.MAX_VALUE, ignoring the previously existing value (the absence of the ,N indicates, essentially, no expiry):

      0899d423-c9e4-4d9b-a46e-a5055df8a23c-2
      

      On the client side, if the branch of code that handles unlocking is never reached, e.g. due to JVM failure, the originally locked node now becomes permanently locked. I am aware of the background thread that every so often looks for the expired open-scoped locks and attempts to get rid of them. However, to such a handler, the lock would still appear as active and not expired.

      Possible Reason

      When a cluster node processes the lock record, for a lock operation it talks to the lock event listener:

      if (record.isLock()) {
          listener.externalLock(record.getNodeId(), record.isDeep(),
                  record.getOwner());
      }
      

      That operation, in turn, defines a new timeout value for the lock, ignoring the previously set one (the one that was obtained from the persistent storage):

      // create lock token
      InternalLockInfo info = new InternalLockInfo(
              nodeId, false, isDeep, lockOwner, Long.MAX_VALUE);
      

      Questions

      1. Am I overlooking something evident here that would tell me that the observed behavior is the one I should expect? Thanks!

      Attachments

        Activity

          People

            Unassigned Unassigned
            illia.khokholkov Illia Khokholkov
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

              Created:
              Updated: