Hi Yes it's most likely the fact the File API does not return a change in the file size, timestamp, which makes Camel think the file is done.
You should use that readLockCheckInterval option. Or you can patch the Camel 2.5 code to have a higher wait time than 1 sec. Or implement a custom processStrategy (for example copy the code from the changed read lock) and use a higher check interval time. On Mon, Nov 28, 2011 at 9:34 PM, GSegel <[email protected]> wrote: > Using Camel 2.5 in JBoss 5.1. > > When dropping large files (over 200MB) into a directory I expected that the > Exchange wouldn't kick off until the file had completed copying. More often > than not, an Exchange is created before it finishes copying. We're using > the 'readLock=changed' option btw. > > Is the reason that it's processing the file before it's done is that the > file size doesn't change over a 1 second interval? This has to be the case > but I just wanted to confirm. > > I might try upgrading to 2.6 or later to see if the 'readLockCheckInterval' > option might resolve the inconsistencies. Thoughts? > > > > > -- > View this message in context: > http://camel.465427.n5.nabble.com/Inconsistent-results-with-File2-readLock-changed-tp5030004p5030004.html > Sent from the Camel - Users mailing list archive at Nabble.com. -- Claus Ibsen ----------------- FuseSource Email: [email protected] Web: http://fusesource.com Twitter: davsclaus, fusenews Blog: http://davsclaus.blogspot.com/ Author of Camel in Action: http://www.manning.com/ibsen/
