camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jean-Michel Morel (Commented) (JIRA)" <>
Subject [jira] [Commented] (CAMEL-3793) Try to copy file when rename fails
Date Thu, 29 Sep 2011 19:19:45 GMT


Jean-Michel Morel commented on CAMEL-3793:

I understand your problem. Have you tried the consumer.exclusiveReadLock parameter ?

> Try to copy file when rename fails
> ----------------------------------
>                 Key: CAMEL-3793
>                 URL:
>             Project: Camel
>          Issue Type: Improvement
>          Components: camel-core
>    Affects Versions: 2.6.0
>         Environment: Linux with NFS mounted directory pointing to a Windows 2008 Server
shared directory
>            Reporter: Jean-Michel Morel
>            Assignee: Claus Ibsen
>             Fix For: 2.8.0
> I have a setup where I use file component to move files after being processed ou when
processing fails.
> As I have no troubles neither on my development workstation neither on local directory
on my linux environnement. It fails when the monitored directory is a NFS mounted directory
pointing to a Windows 2008 Server shared directory.
> While it's not a camel bug, the generated logs are just useless because we can't get
the reason of failure.
> Investigating the source code tells me that the File.renameTo method is used (with the
three times try hack for Windows ;), so I can't get any further information on the reason.
> Could you implement a fallback strategy like copy the file and delete the original one
? (should it be made optional)
> To workaround this, I currently do the move operations manually by invoking the FileUtils.moveTo(...)
from commons-io (which implements exactly the fallback method I described on renameTo failure).
> But, I have side effects as I'm forced to use the noop attribute.
> (in fact, it doesn't explain why the rename fails, but it works, and should it be a failure
I'll get an explicit error message).

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


View raw message