[jira] [Created] (JCR-3978) Incorrect timeout value is used in the utility to synchronize modifications on a lockable node

["Illia Khokholkov (JIRA)" <ji...@apache.org>]

Illia Khokholkov created JCR-3978:
-------------------------------------

             Summary: Incorrect timeout value is used in the utility to synchronize modifications on a lockable node
                 Key: JCR-3978
                 URL: https://issues.apache.org/jira/browse/JCR-3978
             Project: Jackrabbit Content Repository
          Issue Type: Bug
          Components: jackrabbit-jcr-commons
    Affects Versions: 2.11.3
            Reporter: Illia Khokholkov


There appears to be a _possible_ error in the [Locked|https://github.com/apache/jackrabbit/blob/2.11.3/jackrabbit-jcr-commons/src/main/java/org/apache/jackrabbit/util/Locked.java] utility class in that there is no conversion from milliseconds to seconds when a lock manager is requested for a lock for a given node (note that throughout the class, the timeout is expected to be in milliseconds). Consider the following [part|https://github.com/apache/jackrabbit/blob/2.11.3/jackrabbit-jcr-commons/src/main/java/org/apache/jackrabbit/util/Locked.java#L297] of the source code:
{code}
**
* Tries to acquire a session scoped lock on <code>lockable</code>.
*
* @param lockable the lockable node
* @param isDeep   <code>true</code> if the lock should be deep
* @param timeout  time in milliseconds to wait at most to acquire the lock.
* @param isSessionScoped <code>true</code> if the lock is session scoped.
* @return The <code>Lock</code> or <code>null</code> if the
*         <code>lockable</code> cannot be locked.
* @throws UnsupportedRepositoryOperationException
*                             if this repository does not support locking.
* @throws RepositoryException if an error occurs
*/
private static Lock tryLock(Node lockable, boolean isDeep, long timeout, boolean isSessionScoped)
      throws UnsupportedRepositoryOperationException, RepositoryException {
  try {
      LockManager lm = lockable.getSession().getWorkspace().getLockManager();
      return lm.lock(lockable.getPath(), isDeep, isSessionScoped, timeout, null);
  } catch (LockException e) {
      // locked by some other session
  }
  return null;
}
{code}

As indicated in the documentation, the {{timeout}} is expected to be in milliseconds:
{quote}
time in *milliseconds* to wait at most to acquire the lock.
{quote}

However, when the lock manager is [asked|https://github.com/apache/jackrabbit/blob/2.11.3/jackrabbit-jcr-commons/src/main/java/org/apache/jackrabbit/util/Locked.java#L301] for a lock, the timeout is not converted to seconds despite the fact that documentation for the method used indicates that the timeout value is expected in seconds:
{quote}
desired lock timeout in *seconds* (servers are free to ignore this value); specify \{\@link Long#MAX_VALUE\} for no timeout
{quote}

Because of this, it is very easy to get unexpected results from the {{org.apache.jackrabbit.util.Locked}}, especially for the open-scoped locks.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)