Mailing-List: contact dev-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@camel.apache.org
Message-ID: <1130871518.1247347173771.JavaMail.jira@brutus>
Date: Sat, 11 Jul 2009 14:19:33 -0700 (PDT)
From: "Alexander Lee (JIRA)" <jira@apache.org>
To: camel-dev@activemq.apache.org
Subject: [jira] Updated: (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.
In-Reply-To: <1382253280.1247347053740.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit


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

Alexander Lee updated CAMEL-1825:
---------------------------------

          Component/s: camel-core
    Affects Version/s: 2.0-M2

> 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
>
> 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.