The various read locks works differently on different file systems. Especially when another process is writing a large file, then "changed" and "rename" may require a higher timeout / check interval to ensure the file is "really ready".
On Tue, Jun 2, 2015 at 11:07 AM, rwijngaa <rino.van.wijngaar...@gmail.com> wrote: > When i tweak the route some more (added options readLockTimeout and > readLockCheckInterval), the succesrate seems to be 100% now. Is this > expected behaviour? I mean, you would expect the files to be copied with a > 100% successrate no matter what the (timing) options right ? > > Improved route: > > > > > -- > View this message in context: > http://camel.465427.n5.nabble.com/file-to-file-copy-gives-unreliable-results-not-entire-file-is-copied-tp5767775p5767783.html > Sent from the Camel - Users mailing list archive at Nabble.com. -- Claus Ibsen ----------------- Red Hat, Inc. Email: cib...@redhat.com Twitter: davsclaus Blog: http://davsclaus.com Author of Camel in Action: http://www.manning.com/ibsen hawtio: http://hawt.io/ fabric8: http://fabric8.io/
