[
https://issues.apache.org/jira/browse/CAMEL-10505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Poltavtsev updated CAMEL-10505:
--------------------------------------
Description:
Option "readLock=rename" (according to htttp://camel.apache.org/file2.html) is
necessary to lock work file in case of it is not used by another application.
But currently we see "FileNotFound" during test rename operation and "FILE"
component tries to lock and process corresponding work file.
This issue can be resolved by wrapping of corresponding rename operation by
try-catch block. See locally corrected code for
"camel-core/src/main/java/org/apache/camel/component/file/strategy/GenericFileRenameExclusiveReadLockStrategy.java"
in attachment (diff.txt)
was:
Option "readLock=rename" (according to htttp://camel.apache.org/file2.html) is
necessary to lock work file in case of it is not used by another application.
But currently we see "FileNotFound" during test rename operation and "FILE"
component tries to lock and process corresponding work file.
This issue can be resolved by wrapping of corresponding rename operation by
try-catch block. See locally corrected code for
"camel-core/src/main/java/org/apache/camel/component/file/strategy/GenericFileRenameExclusiveReadLockStrategy.java"
@Override
public boolean acquireExclusiveReadLock(GenericFileOperations<T>
operations, GenericFile<T> file,
Exchange exchange) throws Exception
{
LOG.trace("Waiting for exclusive read lock to file: {}", file);
// the trick is to try to rename the file, if we can rename then we
have exclusive read
// since its a Generic file we cannot use java.nio to get a RW lock
String newName = file.getFileName() + ".camelExclusiveReadLock";
// make a copy as result and change its file name
GenericFile<T> newFile = file.copyFrom(file);
newFile.changeFileName(newName);
StopWatch watch = new StopWatch();
boolean exclusive = false;
while (!exclusive) {
// timeout check
if (timeout > 0) {
long delta = watch.taken();
if (delta > timeout) {
CamelLogger.log(LOG, readLockLoggingLevel,
"Cannot acquire read lock within " + timeout + "
millis. Will skip the file: " + file);
// we could not get the lock within the timeout period, so
return false
return false;
}
}
try{
exclusive = operations.renameFile(file.getAbsoluteFilePath(),
newFile.getAbsoluteFilePath());
}catch(GenericFileOperationFailedException ex){
if(ex.getCause() !=null && ex.getCause() instanceof
FileNotFoundException){
exclusive = false;
}else{
throw ex;
}
}
if (exclusive) {
LOG.trace("Acquired exclusive read lock to file: {}", file);
// rename it back so we can read it
operations.renameFile(newFile.getAbsoluteFilePath(),
file.getAbsoluteFilePath());
} else {
boolean interrupted = sleep();
if (interrupted) {
// we were interrupted while sleeping, we are likely being
shutdown so return false
return false;
}
}
}
return true;
}
> "FILE" component with option "readLock=rename" throws FileNotFound exception
> in case of work file is locked/used by another application
> ---------------------------------------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-10505
> URL: https://issues.apache.org/jira/browse/CAMEL-10505
> Project: Camel
> Issue Type: Bug
> Components: camel-core
> Affects Versions: 2.17.3
> Environment: Windows 7 / Java 8.
> Reporter: Andrey Poltavtsev
> Fix For: 2.17.4, 2.18.1, 2.19.0
>
> Attachments: diff.txt
>
>
> Option "readLock=rename" (according to htttp://camel.apache.org/file2.html)
> is necessary to lock work file in case of it is not used by another
> application. But currently we see "FileNotFound" during test rename operation
> and "FILE" component tries to lock and process corresponding work file.
> This issue can be resolved by wrapping of corresponding rename operation by
> try-catch block. See locally corrected code for
> "camel-core/src/main/java/org/apache/camel/component/file/strategy/GenericFileRenameExclusiveReadLockStrategy.java"
> in attachment (diff.txt)
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
