camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claus Ibsen <>
Subject Re: Possible issue with FileLockExclusiveReadLockStrategy leaves orphaned .camelLock file.
Date Wed, 29 Oct 2014 10:27:56 GMT

Yeah good catch. You are welcome to log a JIRA ticket and work on a patch.

On Mon, Oct 27, 2014 at 11:23 PM, David R. Hoffman <> wrote:
> I am trying to understand this block of code in the catch clause of the
> FileLockExclusiveReadLockStrategy acquireExclusiveReadLock() method:
>         } catch (IOException e) {
>             // must handle IOException as some apps on Windows etc. will
> still somehow hold a lock to a file
>             // such as AntiVirus or MS Office that has special locks for
> it's supported files
>             if (timeout == 0) {
>                 // if not using timeout, then we cant retry, so rethrow
>                 throw e;
>             }
>             LOG.debug("Cannot acquire read lock. Will try again.", e);
>             boolean interrupted = sleep();
>             if (interrupted) {
>                 // we were interrupted while sleeping, we are likely being
> shutdown so return false
>                 return false;
>             }
>         }
> This code is outside while loop that controls the timeout to acquire an
> "exclusive lock".  Assuming there is a timeout it calls sleep() which asks
> the thread to sleep for the checkInterval number of millis.  If sleep is not
> interrupted then finally is called to close the RandomAccessFile and
> FileChannel if they have been instantiated and the
> acquireExclusiveReadLock() returns true, indicating that it succeeded in
> acquiring an "exclusive lock."
> The begin() method of the GenericFileProcessStrategySupport is called from
> the processExchange() method of GenericFileConsumer and passes the result of
> acquireExclusiveReadLock() back to the processExchange() in the
> GenericFileConsumer which then would try process the file without really
> acquiring an "exclusive lock", and there is no code that I can find that
> would support the log message: "Cannot acquire read lock. Will try again."
> When the begin() method is called from the GenericFileProcessStrategySupport
> subclass GenericFileRenameProcessStrategy, as with "preMove", the begin()
> method of GenericFileRenameProcessStrategy will try to rename the file.
> using in our case renameUsingCopy,and this will fail with a
> FileNotFoundException from the FileInputStream constructor in the copyFile()
> method of the FileUtil class if there is actually a file system lock on the
> file.
> It seems to me that the catch clause should simply return false allowing the
> GenericFileConsumer to call the GenericFileProcessStrategySupport abort()
> method and in turn the FileLockExclusiveReadLockStrategy and superclass
> MarkerFileExclusiveReadLockStrategy releaseExclusiveReadLock() methods.  By
> failing to call abort with end up with an orphaned .camelLock file, and the
> target file will not be eligible to process again on the next poll.
> I am also not sure why we check timeout == 0 in the catch clause and
> re-throw the IOException when true, because this also leads to an orphaned
> .camelLock file.
> A similar issue exists using the FileChangedExclusiveReadLockStrategy where
> the FileUtil.copyFile() method throws a FileNotFoundException because there
> is still a file system lock on the file.
> I came across the questionable code in the FileLockExclusiveReadLockStrategy
> catch block while trying to combine the FileChangedExclusiveReadLockStrategy
> with the FileLockExclusiveReadLockStrategy after we ran into the issue where
> the FileChangedExclusiveReadLockStrategy acquireExclusiveReadLock() method
> returned true but there was still a file system lock on the file.
> --
> View this message in context:
> Sent from the Camel - Users mailing list archive at

Claus Ibsen
Red Hat, Inc.
Twitter: davsclaus
Author of Camel in Action:

View raw message