[ 
https://issues.apache.org/jira/browse/CAMEL-6069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14325721#comment-14325721
 ] 

Baris Acar commented on CAMEL-6069:
-----------------------------------

[~andersmholmgren] - are you _certain_ that it was the thread/process that 
raised the exception that created the file, and not some other process?

We are having problems with the current implementation as per your proposal, as 
it introduces race conditions into the locking mechanism, and allows multiple 
threads or processes to lock the same file at once.
See 
http://camel.465427.n5.nabble.com/FileUtil-createNewFile-race-condition-issue-td5762853.html#a5762897

> java.io.IOException: Permission denied from 
> MarkerFileExclusiveReadLockStrategy.acquireExclusiveReadLock on NAS
> ---------------------------------------------------------------------------------------------------------------
>
>                 Key: CAMEL-6069
>                 URL: https://issues.apache.org/jira/browse/CAMEL-6069
>             Project: Camel
>          Issue Type: Bug
>          Components: camel-core
>    Affects Versions: 2.10.3
>            Reporter: Anders Holmgren
>            Assignee: Claus Ibsen
>            Priority: Minor
>             Fix For: 2.10.4, 2.11.0
>
>
> We recently upgraded to 2.10.x and discovered that the file poller no longer 
> works on our NAS. We have hit similar issues with other open source libraries 
> in the past.
> The problem occurs when 
> MarkerFileExclusiveReadLockStrategy.acquireExclusiveReadLock is called and 
> tries to create the new file. This actually works but also results in a 
> Permission denied IOException (strange but true). 
> A simple fix for this is to change the acquireExclusiveReadLock method as 
> follows. 
> {code}
>     public boolean acquireExclusiveReadLock(GenericFileOperations<File> 
> operations,
>                                             GenericFile<File> file, Exchange 
> exchange) throws Exception {
>         String lockFileName = getLockFileName(file);
>         LOG.trace("Locking the file: {} using the lock file name: {}", file, 
> lockFileName);
>         // create a plain file as marker filer for locking (do not use 
> FileLock)
>         File lock = new File(lockFileName);
>         boolean acquired = false;
>         try
>         {
>             acquired = lock.createNewFile();
>         }
>         catch (IOException e)
>         {
>             if (lock.exists())
>             {
>                 acquired = true;
>             }
>             else
>             {
>                 throw e;
>             }
>         }
>         return acquired;
>     }
> {code}
> Note the same problem occurring with Spring Batch can be found 
> [here|https://jira.springsource.org/browse/BATCH-1659] 



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

Reply via email to