Quartz job to read wildcard filename only picks up one file - mule

Question

Using Mule 3.7. If I have 5 files in a directory with a .csv extension the below code only picks up one of the five files. If I remove the quartz trigger and make it a normal file:inbound-endpoint it picks up all five files. It seems so simple but does not work as intended.
Thanks,
-- Don
<?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>
Here is the log after it firing twice:
INFO 2015-10-05 15:09:30,063 [scheduler-quartzcronfilepickup_Worker-1] org.mule.lifecycle.AbstractLifecycleManager: Initialising: 'fileInConnector.requester.2009817243'. Object is: FileMessageRequester
INFO 2015-10-05 15:09:30,069 [scheduler-quartzcronfilepickup_Worker-1] org.mule.lifecycle.AbstractLifecycleManager: Starting: 'fileInConnector.requester.2009817243'. Object is: FileMessageRequester
INFO 2015-10-05 15:09:30,117 [[quartzcronfilepickup].fileUploader.stage1.02] org.mule.api.processor.LoggerMessageProcessor: Filename=D1.csv
INFO 2015-10-05 15:09:45,015 [scheduler-quartzcronfilepickup_Worker-2] org.mule.lifecycle.AbstractLifecycleManager: Initialising: 'fileInConnector.requester.636902426'. Object is: FileMessageRequester
INFO 2015-10-05 15:09:45,016 [scheduler-quartzcronfilepickup_Worker-2] org.mule.lifecycle.AbstractLifecycleManager: Starting: 'fileInConnector.requester.636902426'. Object is: FileMessageRequester
INFO 2015-10-05 15:09:45,022 [[quartzcronfilepickup].fileUploader.stage1.02] org.mule.api.processor.LoggerMessageProcessor: Filename=D1.csv

Answer 1

There is a major difference between using a polling file inbound-endpoint and a Quartz inbound-endpoint polling a file endpoint: the former uses a message receiver, while the latter uses a message requester. Being two different beasts, they have the potential to be implemented quite differently.
And, guess what?, that's exactly the case for files. The file message receiver uses a lock mechanism to prevent polling a file that is being processed, while the requester does not.
The fun bit is this comment in the source code of the requester:
// Don't we need to try to obtain a file lock as we do with receiver
This doubt and the lack of lock usage in the requester is what makes it behave differently than the receiver. The fact this has never been solved for sure probably means that adding a lock there has undesired side-effects.
In any case, if you persist in using Quartz, I suggest you move the file being processed to another directory to prevent having it re-polled. The file endpoint should be able to do the move for you.