Hi 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.
On Thu, Mar 19, 2020 at 12:57 AM Mark Harris <[email protected]> wrote: > > Hello, > > Can anyone suggest what the problem is here, please? It sounds like a pretty > fundamental issue but I have not managed to find any similar reports (and > potential solutions) elsewhere. > > Thanks, > > Mark > > From: Mark Harris > Sent: 18 March 2020 14:51 > To: [email protected] > Subject: RE: Cannot acquire read lock within x millis > > I should add that I'm seeing the "Cannot acquire read lock within x millis" > messages appear in the logs of both application servers several seconds > apart, implying that the two instances are not polling at precisely the same > time. Yet neither of them are able to process the file for several rounds of > polling before one of them does. > > Thanks, > > Mark > > From: Mark Harris > Sent: 18 March 2020 13:55 > To: [email protected]<mailto:[email protected]> > Subject: Cannot acquire read lock within x millis > > Hello, > > I'm encountering the following message in my logs when two instances of a > Java application running Camel on separate servers (to ensure HA) are trying > to poll an sFTP server to process a file: > > Cannot acquire read lock within 20000 millis. Will skip the file: > RemoteFile[name and path of file on sFTP server] > > The route URI is like this: > > sftp://<user>@<server>:<port>/<path>?connectTimeout=120000&delay=60s&delete=true&disconnect=true&ignoreFileNotFoundOrPermissionError=true&inProgressRepository=<repository>&include=<mask>&password=<password>&readLock=changed&readLockMinAge=10s&soTimeout=300000 > > The process copies the file to a local shared folder where it is further > processed by routes running on the same 2 Java applications with a URI like > this: > > file://<path>?delay=60s&inProgressRepository=<repository>&include=<mask>&readLock=changed&readLockMinAge=10s<file://%3cpath%3e?delay=60s&inProgressRepository=%3crepository%3e&include=%3cmask%3e&readLock=changed&readLockMinAge=10s> > > ... where I also get the same message: > > Cannot acquire read lock within 10000 millis. Will skip the file: > GenericFile[name and path of file on shared folder] > > Eventually the file is processed but it is taking several polls before one of > the applications processes the file, leading to delays. > > Can anyone advise what the issue is and how I can fix it, please? > > I'm using Camel v 2.24.2. > > Thanks, > > Mark > -- Claus Ibsen ----------------- http://davsclaus.com @davsclaus Camel in Action 2: https://www.manning.com/ibsen2
