urunni88 commented on PR #28039: URL: https://github.com/apache/camel/pull/28039#issuecomment-6260459014
@davsclaus I reproduced it with DEBUG logging on the original test (2 failures in 80 runs, locally on Windows). In both failures only one file was routed twice: the first file that reached mock:bar. The log of one failing run, for b.txt: ``` 12.619 [disruptor://foo] Done processing file: GenericFile[b.txt] 12.620 [main] camel-34 is shutting down 12.637 [disruptor://foo] Renaming file: GenericFile[b.txt] to: GenericFile[.camel\b.txt] 12.663 [arget/disruptor] Took 41ms to poll: target\disruptor 12.663 [arget/disruptor] Total 1 files to consume 12.667 [arget/disruptor] About to process file: GenericFile[b.txt] 13.678 [disruptor://foo] mock:bar receives b.txt a second time 13.685 [disruptor://foo] WARN Error during commit ... Cannot rename file: GenericFile[b.txt] to: GenericFile[.camel\b.txt] ``` So it is the file consumer, not the disruptor, and you were right that a file in flight is not picked up again: the second pick-up came after the first exchange of b.txt had completed. The poll that picked it up took 41 ms, so it started at about 12.622, before the rename at 12.637. It looks like the poll listed the directory before the commit moved b.txt, and checked the in-progress repository after the commit had removed it, so it routed a file that was already moved, and its commit then failed. This poll also ran after the context had started shutting down. With syncDelayed() the commit runs on the poll thread, so a poll never overlaps a commit, which is why the test is stable with it. Should I open a JIRA for this race in the file consumer? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
