Camel utilise-t-il un verrou de lecture implicite pour les fichiers?

Question

Je suis la consommation d'un fichier à l'aide Camel fichier composant comme suit:

<from uri="file:myDir?noop=true&amp;filter=myFilter&amp;scheduler=quartz2&amp;scheduler.cron={{schedule}}/> 

L'emplacement de la source est en lecture seule. Camel File documentation dit, il n'utilisera pas un verrou de lecture par défaut. Mais, j'obtiens une exception d'autorisation refusée lors de l'exécution de ce code.

Endpoint [file: // myFile filtre = myFilter & idempotent = true & = true noop & planificateur = quartz2 & scheduler.cron = {{}} mySchedule ne peut pas commencer fichier de traitement: GenericFile [myDir \ myFile ] en raison de: Accès est refusée. Causée par: [java.io.IOException - Accès refusé]

Stack Trace java.io.IOException: Permission refusée à java.io.UnixFileSystem.createFileExclusively (Native Method) [: 1.8.0_66] à java .io.Fichier.createNewFile (Fichier.java:1012) [: 1.8.0_66] à org.apache.camel.util.FileUtil.createNewFile (FileUtil.java:587) [org.apache.camel: camel-core: 2.15.1.redhat-621090 com.googlecode.concurrentlinkedhashmap: concurrentlinkedhashmap-LRU: 1.4.2] à org.apache.camel.component.file.strategy.MarkerFileExclusiveReadLockStrategy.acquireExclusiveReadLock (MarkerFileExclusiveReadLockStrategy.java:71) [org. apache.camel: camel-core: 2.15.1.redhat-621090 com.googlecode.concurrentlinked hashmap: concurrentlinkedhashmap-lru: 1.4.2] à org.apache.camel.component.file.strategy.GenericFileProcessStrategySupport.begin (GenericFileProcessStrategySupport.java:49) [org.apache.camel: camel-core: 2.15.1. redhat-621090 com.googlecode.concurrentlinkedhashmap: concurrentlinkedhashmap-LRU: 1.4.2] à org.apache.camel.component.file.strategy.GenericFileRenameProcessStrategy.begin (GenericFileRenameProcessStrategy.java:35) [org.apache.camel: camel-core: 2.15.1.redhat-621090 com.googlecode.concurrentlinkedhashmap: concurrencechampmap-lru: 1.4.2] à org.apache.camel.component.file.GenericFileConsumer.processExchange (GenericFileConsumer.java:352) [ org.apache.camel: camel-core: 2.15.1.redhat-621090 com.googlecode.concur rentlinkedhashmap: concurrentlinkedhashmap-lru: 1.4.2] à org.apache.camel.component.file.GenericFileConsumer.processBatch (GenericFileConsumer.java:211) [org.apache.camel: chameau-core: 2.15.1.redhat- 621090 com.googlecode.concurrentlinkedhashmap: concurrentlinkedhashmap-lru: 1.4.2] à org.apache.camel.component.file.GenericFileConsumer.poll (GenericFileConsumer.java:175) [org.apache.camel: camel-core: 2.15.1.redhat-621090 com.googlecode.concurrentlinkedhashmap: concurrentlinkedhashmap-lru: 1.4.2] à org.apache.camel.impl.ScheduledPollConsumer.doRun (ScheduledPollConsumer.java:174) [org.apache.camel: chameau-core: 2.15.1.redhat-621090 com.googlecode.concurrentlinkedhashmap: concurrentlinkedhashmap-lru: 1.4.2] à org.apache.camel.impl.ScheduledPollConsumer.run (ScheduledPollConsumer.java:101) [org.apache.camel: chameau-core: 2.15.1.redhat-621090 com.googlecode.concurrentlinkedhashmap: concurrentlinkedhashmap-lru: 1.4.2] à org.apache.camel.pollconsumer.quartz2.QuartzScheduledPollConsumerJob.execute (QuartzScheduledPollConsumerJob.java:59) [org.apache.camel: camel-quartz2: 2.15.1.redhat-621090] à org .quartz.core.JobRunShell.run (JobRunShell.java:202) [org.-Scheduler quartz: quartz: 2.2.1] à org.quartz.simpl.SimpleThreadPool $ WorkerThread.run (SimpleThreadPool.java:573) [org.quartz-programmateur: quartz: 2.2.1]

De la trace de la pile, il semble que camel essaie de créer un readLock et provoque une exception en raison d'un manque de permission.

Alors, mes questions sont

• Pourquoi chameau utilise un verrou, même si la valeur par défaut de verrouillage de lecture est aucun
• Si ce comportement est normal, comment puis-je consommer fichier à partir d'une lecture seul endroit où je n'ai pas la permission d'écriture?

MISE À JOUR

J'ai essayé la mise en readLockMarkingFile-false comme suggéré dans l'une de la réponse, mais cela ne résout pas le problème. Donc, j'ai explicitement mis readLock à none. Maintenant, ça marche. Je ne sais pas, pourquoi readLock n'est pas none par défaut comme mentionné dans la documentation.

Answer 1

L'option readLock décide uniquement si camel tentera d'acquérir un verrou de lecture exclusif sur le fichier. Il y a une autre option appelée "readLockMarkerFile" qui a la valeur true par défaut, définissez cette option sur false et cela devrait aller.

<from uri="file:myDir?noop=true&amp;filter=myFilter&amp;scheduler=quartz2&amp;scheduler.cron={{schedule}}&amp;readLockMarkerFile=false/> 

Answer 2

Bien que cela ne répond pas directement à votre question, je l'ai utilisé un fichier de déclenchement (0 octets) que le veilleur de fichier cherche. Votre itinéraire fonctionnerait alors sur le fichier réel auquel le déclencheur est un compagnon. Le fichier trigger est déplacé dans un sous-répertoire /parent/.camel afin qu'il ne soit pas traité à nouveau. Bien que nous ayons remarqué que les routes essayent de "ramasser" le fichier réel dans un environnement distribué où plus d'un serveur exécute la route.