file-to-file copy gives unreliable results (not entire file is copied)
Hi, I'm trying to reproduce a problem we have in production with one of our camel routes, in the process i found some strange behaviour when just copying a file with a simple blueprint camel route (see below). Small (zip) files seem to be copied correctly, but large files (i used 162MB) sometimes end up as 162MB (good!), 26MB, 96MB, 50MB or otherwise corrupted. I played with several options (bufferSize, delay, etc) but to no avail. I'm testing this with a clean install of ServiceMix 5.4.0 (camel 2.14.1) on a macbookpro This is the camel route i deployed: Regards Rino -- View this message in context: http://camel.465427.n5.nabble.com/file-to-file-copy-gives-unreliable-results-not-entire-file-is-copied-tp5767775.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: file-to-file copy gives unreliable results (not entire file is copied)
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.
Re: file-to-file copy gives unreliable results (not entire file is copied)
BTW: My colleague copying a 1GB file with the same blueprint route on Windows 8 seems to have no problem at all ! -- View this message in context: http://camel.465427.n5.nabble.com/file-to-file-copy-gives-unreliable-results-not-entire-file-is-copied-tp5767775p5767779.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: file-to-file copy gives unreliable results (not entire file is copied)
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/
