when a file that is locked by another process is picked up by the SOA platform, and the rename fails, we get a error logg eventhough the file is processed successfully on the next attempt (when the lock is gone). ---- 2012-05-31 08:43:56,694 DEBUG [org.jboss.soa.esb.util.FileUtil] (ESBScheduler:AnalytixImport.esb_Worker-0) Unable to perform local rename of file 'c:\ipl\itg_kemlabsvar\inbox\D5V843AV.xml' to 'c:\ipl\itg_kemlabsvar\inbox\9f5d7a61-a564-483a-bea6-054331c640d0.D5V843AV.xml.9f5d7a61-a564-483a-bea6-054331c640d0'. Unable to move file. 2012-05-31 08:43:56,695 ERROR [org.jboss.soa.esb.listeners.gateway.AbstractFileGateway] (ESBScheduler:AnalytixImport.esb_Worker-0) Composer <org.jboss.soa.esb.listeners.gateway.LocalFileMessageComposer> Failed. org.jboss.soa.esb.listeners.message.MessageDeliverException: Invalid File payload. File 'c:\ipl\itg_kemlabsvar\inbox\D5V843AV.xml.lck' doesn't exist. ---- The call chain here seems to be 1) AbstractFileGateway.onSchedule() 2) AbstractFileGateway.setFileWorking(fileIn); 3) FileGatewayListener.renameFile(from,to); 4) FileUtil.renameTo(from, to) The problem is that FileUtil.renameTo(..) returns true even if it fails to rename the file (in the step where it renames a localfile to a filename that includes the UUID). This in turn makes setFileWorking(..) return a non-null value and AbstractFileGateway will go ahead and try to process the non-existing file.
Change set: 333,334c333 < this.establishDeployedContentList(this.deploymentDir); < scan(true, deploymentOperations); --- > scan(true, deploymentOperations);
Created attachment 644973 [details] Includes fixes. Attached file includes fixes.
(In reply to comment #1) > Change set: > > 333,334c333 > < this.establishDeployedContentList(this.deploymentDir); > < scan(true, deploymentOperations); > --- > > scan(true, deploymentOperations); --------------------------------------------------------------------------------- Please disregard comment 1. The real changeset is below. Thanks, Rick ]0;rick@rwagner01:~/Junk/a/b[?1034h[rick@rwagner01 b]$ diff *old* *new* 113,114c113,114 < LOGGER.debug("Unable to perform local rename of file '" + from.getAbsolutePath() + "' to '" + fromLocalRename.getAbsolutePath() + "'. Unable to move file."); < return true; --- > LOGGER.debug("Unable to perform local rename of file '" + from.getAbsolutePath() + "' to '" + fromLocalRename.getAbsolutePath() + "'. Unable to move file."); > return false; 120c120 < return true; --- > return false; 131c131 < return true; --- > return false; 209,213c209,213 < try < { < fos.close(); < } < catch (final IOException ioe) {} // ignore --- > try > { > fos.close(); > } > catch (final IOException ioe) {} // ignore 220c220 < fis.close(); --- > fis.close(); 238c238 < while( (reader.read(chars)) > -1){ --- > while( (reader.read(chars)) > -1) {
This BZ originated after fix BZ 829876 (on SOA-P 5.1).
The easiest way to test this I think is to write a test that opens a file in append mode (the goal is to have a file lock). Then, while the file is open in append mode, call FileUtils.move() on it.
Tom Cunningham <tcunning> updated the status of jira JBESB-3882 to Resolved
Tom Cunningham <tcunning> updated the status of jira JBESB-3882 to Closed
Reproduced this on Windows using David B's suggestion (see FileUtilUnitTest.test_renameTo).