I'm using Camel 2.6.0 and I've noticed some odd behavior with regard to file locking. Here are the routing details:
<route> <from uri="file://dir?delay=5000&move=.archive&moveFailed=.failed&readLock=fileLock"/> <convertBodyTo type="java.lang.String"/> <bean ref="beanProcessor"> </route> The data file to be processed is a small .csv file that is routed to the "beanProcessor" for processing. The "beanProcessor" is an AsyncProcessor. Processing is quite complex and I've omitted these details for now. When the readLock option is "fileLock" and a file is dropped into dir, processing fails and an IOException is produced with this message: The process cannot access the file because another process has locked a portion of the file. When the readLock option is "rename" and a file is dropped into dir, processing works correctly. When the readLock option is not set, several .camelLock files remain on the file system and are not cleaned up. I've researched this a bit and while it is reported as fixed, the files are still not cleaned up properly in my environment. (Windows with a local file system in DEV and Windows with a NetApp filer in QA/Prod.) Question: Is this a bug or is it expected behavior? The fileLock option performs a bit better and I'd prefer to use it if it can be made to work. I can fail back to rename if needed, however. -- View this message in context: http://camel.465427.n5.nabble.com/Camel-2-6-0-Locking-with-the-file-component-tp3397667p3397667.html Sent from the Camel - Users mailing list archive at Nabble.com.
