> Its been talked about before, that changed read-locks on FTP servers is not > "so fast" because FTP server > often returns file information / file lists with only hh:mm information and > not seconds, so a change > strategy cannot use seconds to know if a file was changed or not.
Is there an alternative strategy that I can use? The scenario is that I have two applications polling an sFTP server for new files every 30 seconds; any new file needs to be at least 10 seconds old, picked up as soon as possible after this period and processed by only one of the applications. I'm currently using readLock=changed, a readLockMinAge and an inProgressRepository to ensure idempotency in my route URI. Thanks, Mark
