camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claus Ibsen <>
Subject Re: Inconsistent results with File2 'readLock=changed'
Date Tue, 29 Nov 2011 15:20:57 GMT

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 <> 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:
> Sent from the Camel - Users mailing list archive at

Claus Ibsen
Twitter: davsclaus, fusenews
Author of Camel in Action:

View raw message