You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by "Claus Ibsen (JIRA)" <ji...@apache.org> on 2009/07/12 09:03:33 UTC

[jira] Assigned: (CAMEL-1825) GenericFileDeleteProcessStrategy in some cases seems to delete a file, but then throw an exception saying it can't delete the file, even though it has.

     [ https://issues.apache.org/activemq/browse/CAMEL-1825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Claus Ibsen reassigned CAMEL-1825:
----------------------------------

    Assignee: Claus Ibsen

> GenericFileDeleteProcessStrategy in some cases seems to delete a file, but then throw an exception saying it can't delete the file, even though it has.
> -------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: CAMEL-1825
>                 URL: https://issues.apache.org/activemq/browse/CAMEL-1825
>             Project: Apache Camel
>          Issue Type: Bug
>          Components: camel-core
>    Affects Versions: 2.0-M2
>         Environment: Red Hat Linux., Java 1.5_17, Mounted network share.
>            Reporter: Alexander Lee
>            Assignee: Claus Ibsen
>
> In some cases, GenericFileDeleteProcessStrategy seems to delete a file, but then it throws an exception saying it can't delete the file, even though it has.  Because this happens, it causes a rollback even though the file has been processed and deleted correctly.  This only seems to happen on our Linux box which is using a network share to process files from.  We have managed to work around it by checking if the file exists again straightaway after "operations.deleteFile(...)", and this always says the file does not exist as expected, so not sure why the call  "operations.deleteFile(...)" returns false.  The modified code below works around this issue, and logs a warning if the file still exists (though you may wish to throw and exception instead), but so far the log statement has not been called in our test runs even though it does enter the " if (!deleted)" block.
>     @Override
>     public void commit(GenericFileOperations<T> operations, GenericFileEndpoint<T> endpoint, GenericFileExchange<T> exchange, GenericFile<T> file) throws Exception {
>         // must invoke super
>         super.commit(operations, endpoint, exchange, file);
>         boolean deleted = operations.deleteFile(file.getAbsoluteFilePath());
>         if (!deleted) {
>             final File javaFile = new File(file.getAbsoluteFilePath());
>             if (javaFile.exists()) {
>                 log.warn("Cannot delete file: " + file);
>             }
>         }
>     }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.