You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by "Jean-Michel Morel (JIRA)" <ji...@apache.org> on 2011/03/21 14:17:05 UTC
[jira] [Created] (CAMEL-3793) Try to copy file when rename fails
Try to copy file when rename fails
----------------------------------
Key: CAMEL-3793
URL: https://issues.apache.org/jira/browse/CAMEL-3793
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
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.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-3793) Try to copy file when rename fails
Posted by "Jean-Michel Morel (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-3793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13117551#comment-13117551 ]
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: https://issues.apache.org/jira/browse/CAMEL-3793
> 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: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-3793) Try to copy file when rename fails
Posted by "Maria Iracheta (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-3793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13118068#comment-13118068 ]
Maria Iracheta commented on CAMEL-3793:
---------------------------------------
Thanks Jean-Michel Morel for the suggestion, we might try to implement our own org.apache.camel.component.file.GenericFileExclusiveReadLockStrategy for the time being.
Thanks Claus, I have raised an improvement ticket, CAMEL-4505, it also includes what I think is a bug in the FileUtils copy/delete area.
> Try to copy file when rename fails
> ----------------------------------
>
> Key: CAMEL-3793
> URL: https://issues.apache.org/jira/browse/CAMEL-3793
> 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: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CAMEL-3793) Try to copy file when rename fails
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-3793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Claus Ibsen updated CAMEL-3793:
-------------------------------
Fix Version/s: 2.8.0
What don't we do for our windows users ;)
> Try to copy file when rename fails
> ----------------------------------
>
> Key: CAMEL-3793
> URL: https://issues.apache.org/jira/browse/CAMEL-3793
> 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.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-3793) Try to copy file when rename fails
Posted by "Claus Ibsen (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-3793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13117896#comment-13117896 ]
Claus Ibsen commented on CAMEL-3793:
------------------------------------
Maria good idea, can you create a new ticket? I also think it should be configurable.
> Try to copy file when rename fails
> ----------------------------------
>
> Key: CAMEL-3793
> URL: https://issues.apache.org/jira/browse/CAMEL-3793
> 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: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CAMEL-3793) Try to copy file when rename fails
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-3793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Claus Ibsen reassigned CAMEL-3793:
----------------------------------
Assignee: Claus Ibsen
> Try to copy file when rename fails
> ----------------------------------
>
> Key: CAMEL-3793
> URL: https://issues.apache.org/jira/browse/CAMEL-3793
> 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
>
> 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.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-3793) Try to copy file when rename fails
Posted by "Maria Iracheta (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-3793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13117373#comment-13117373 ]
Maria Iracheta commented on CAMEL-3793:
---------------------------------------
I can see why this change was made in the rename method of FileUtil, but this change has created a problem for us:
- Before: if a file was opened in Windows, the renaming method was not working, so the File was not being moved and therefore it was not being processed. It would fail and let the user know that the file could not be renamed.The file was not being processed.
- Now: if it cannot rename it, after 3 tries it will copy it (the processing of the file starts) and then fails to delete it, what means that it will be endlessly process the file until somebody realises.
Is it possible to make the feature of copy/delete instead of rename configurable? Or is there any way of preventing the endlessly processing of a File that is opened by a user in Windows that could come out of box with Camel File? Or should we implement our own thing?
> Try to copy file when rename fails
> ----------------------------------
>
> Key: CAMEL-3793
> URL: https://issues.apache.org/jira/browse/CAMEL-3793
> 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: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CAMEL-3793) Try to copy file when rename fails
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-3793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Claus Ibsen resolved CAMEL-3793.
--------------------------------
Resolution: Fixed
> Try to copy file when rename fails
> ----------------------------------
>
> Key: CAMEL-3793
> URL: https://issues.apache.org/jira/browse/CAMEL-3793
> 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.
For more information on JIRA, see: http://www.atlassian.com/software/jira