Re: Possible issue with FileLockExclusiveReadLockStrategy leaves orphaned .camelLock file.

[Claus Ibsen <cl...@gmail.com>]

Hi

I logged a ticket and work on this to get this fixed. Thanks for
reporting so detailed.
https://issues.apache.org/jira/browse/CAMEL-7988

On Wed, Oct 29, 2014 at 11:27 AM, Claus Ibsen <cl...@gmail.com> wrote:
> 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 <dh...@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/



-- 
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/