Кварцевое задание для чтения подстановочного имени файла подбирает только один файл

Question

Использование Mule 3.7. Если у меня есть 5 файлов в каталоге с расширением .csv, нижеприведенный код подбирает только один из пяти файлов. Если я удалю кварцевый триггер и сделаю его обычным файлом: входящая-конечная точка, он забирает все пять файлов. Это кажется таким простым, но не работает должным образом.
Спасибо,
- Дон

<?xml version="1.0" encoding="UTF-8"?> 

<mule xmlns:json="http://www.mulesoft.org/schema/mule/json" xmlns:scripting="http://www.mulesoft.org/schema/mule/scripting" xmlns:context="http://www.springframework.org/schema/context" xmlns:quartz="http://www.mulesoft.org/schema/mule/quartz" 
    xmlns:file="http://www.mulesoft.org/schema/mule/file" xmlns="http://www.mulesoft.org/schema/mule/core" xmlns:doc="http://www.mulesoft.org/schema/mule/documentation" xmlns:spring="http://www.springframework.org/schema/beans" version="EE-3.6.1" 
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
    xsi:schemaLocation=" 
http://www.mulesoft.org/schema/mule/json http://www.mulesoft.org/schema/mule/json/current/mule-json.xsd 
http://www.mulesoft.org/schema/mule/scripting http://www.mulesoft.org/schema/mule/scripting/current/mule-scripting.xsd 
http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-current.xsd http://www.mulesoft.org/schema/mule/quartz http://www.mulesoft.org/schema/mule/quartz/current/mule-quartz.xsd 
http://www.mulesoft.org/schema/mule/file http://www.mulesoft.org/schema/mule/file/current/mule-file.xsd 
http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-current.xsd 
http://www.mulesoft.org/schema/mule/core http://www.mulesoft.org/schema/mule/core/current/mule.xsd"> 
    <file:connector name="fileInConnector" autoDelete="false" streaming="true" validateConnections="true" doc:name="FileConnector" /> 
    <file:endpoint name="fileInEndpoint" path="\\\\c:\\scratch" connector-ref="fileInConnector" doc:name="FileEndpoint"> 
     <file:filename-wildcard-filter pattern="*.csv" /> 
    </file:endpoint> 
    <flow name="fileUploader"> 
     <quartz:inbound-endpoint jobName="getFilesTrigger" cronExpression="/15 * * * * ?" doc:name="Quartz"> 
      <quartz:endpoint-polling-job> 
       <quartz:job-endpoint ref="fileInEndpoint" /> 
      </quartz:endpoint-polling-job> 
     </quartz:inbound-endpoint> 
     <logger message="Filename=#[message.inboundProperties.originalFilename]" level="INFO" doc:name="Logger" /> 
    </flow> 
</mule> 

Вот лог после него стрельбы дважды:
INFO 2015-10-05 15: 09: 30063 [планировщик-quartzcronfilepickup_Worker-1] org.mule.lifecycle .AbstractLifecycleManager: Инициализация: 'fileInConnector.requester.2009817243'. Объект: FileMessageRequester
INFO 2015-10-05 15: 09: 30,069 [scheduler-quartzcronfilepickup_Worker-1] org.mule.lifecycle.AbstractLifecycleManager: Запуск: 'fileInConnector.requester.2009817243'. Объект: FileMessageRequester
ИНФО 2015-10-05 15: 09: 30117 [[quartzcronfilepickup] .fileUploader.stage1.02] org.mule.api.processor.LoggerMessageProcessor: Имя файла = D1.csv
ИНФО 2015- 10-05 15: 09: 45,015 [scheduler-quartzcronfilepickup_Worker-2] org.mule.lifecycle.AbstractLifecycleManager: Инициализация: 'fileInConnector.requester.636902426'. Объект: FileMessageRequester
INFO 2015-10-05 15: 09: 45,016 [scheduler-quartzcronfilepickup_Worker-2] org.mule.lifecycle.AbstractLifecycleManager: Запуск: 'fileInConnector.requester.636902426'. Объект: FileMessageRequester
ИНФО 2015-10-05 15: 09: 45022 [[quartzcronfilepickup] .fileUploader.stage1.02] org.mule.api.processor.LoggerMessageProcessor: Имя файла = D1.csv

Answer 1

Там является существенным различием между использованием входящей-конечной точки опроса и входящей-конечной точкой Quartz, опрашивающей конечную точку файла: первая использует приемник , в то время как последний использует реквестер . Будучи двумя разными животными, они могут быть реализованы совершенно по-другому.

И, угадайте, что ?, это точно так же касается файлов. Приемник сообщений файла uses a lock mechanism для предотвращения опроса обрабатываемого файла, а requester does not.

Забава бит этот комментарий в исходном коде запрашивающей:

// Don't we need to try to obtain a file lock as we do with receiver 

Это сомнение и отсутствие использования замка в запрашивающей, что делает его вести себя иначе, чем приемник. Тот факт, что это никогда не было разрешено, вероятно, означает, что добавление блокировки имеет нежелательные побочные эффекты.

В любом случае, если вы продолжаете использовать Quartz, я предлагаю вам переместить обрабатываемый файл в другой каталог, чтобы предотвратить повторное опрос. Конечная точка файла должна быть в состоянии сделать ход для вас.