camel-users mailing list archives

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

Yeah good catch. You are welcome to log a JIRA ticket and work on a patch.
http://camel.apache.org/contributing.html

On Mon, Oct 27, 2014 at 11:23 PM, David R. Hoffman <dhoffman@capario.com> 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: http://camel.465427.n5.nabble.com/Possible-issue-with-FileLockExclusiveReadLockStrategy-leaves-orphaned-camelLock-file-tp5758142.html
> Sent from the Camel - Users mailing list archive at Nabble.com.



-- 
Claus Ibsen
-----------------
Red Hat, Inc.
Email: cibsen@redhat.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen
hawtio: http://hawt.io/
fabric8: http://fabric8.io/

Mime
View raw message