[
https://issues.apache.org/jira/browse/CAMEL-7525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-7525.
--------------------------------
Resolution: Fixed
There is a new option readLockMarkerFile you can use to turn off.
> Behavior change for file component in 2.10 causes problems with no workaround
> available
> ---------------------------------------------------------------------------------------
>
> Key: CAMEL-7525
> URL: https://issues.apache.org/jira/browse/CAMEL-7525
> Project: Camel
> Issue Type: Improvement
> Components: camel-core
> Affects Versions: 2.13.0
> Reporter: Knut-HÃ¥vard Aksnes
> Assignee: Claus Ibsen
> Fix For: 2.14.0
>
>
> We do use the file component to read files from a particular area. We pick
> up new files from there using their content as basis for a database import.
> There are a couple of important points:
> # We must not add or delete files to the area we read from, not even
> temporarily.
> # We need to pick up files once.
> To achive this we use noop=true as well as a file based idempotentRepository
> where the repository is placed in a different location. We also use
> readLock=changed which is the big problem. To cite the component
> documentation:
> Notice from Camel 2.10 onwards the read locks changed, fileLock and rename
> will also use a markerFile as well, to ensure not picking up files that may
> be in process by another Camel consumer running on another node (eg cluster).
> This is a huge problem as I can't find any documented way of storing the
> marker files in a different location. What is really needed is something
> similar to inProgressRepository as an option to keep track of the readLock
> related information. Alternatively an option to disable the marker files
> could be created, this option could however lead to failure if applications
> are clustered.
> This problem is for us serious breakage, as there are other applications not
> under our control reading the same areas, some of these crashes due to the
> marker files.
--
This message was sent by Atlassian JIRA
(v6.2#6252)