Mule File inbound endpoint fileAge not working

Question

In a simple flow using mule 3.7 EE we are monitoring a directory for files to move them using a File inbound-endpoint. I set the parameters to poll at 5 minute intervals (300000ms) and require of fileAge of the same (300000ms). This works fine in the Anypoint environment on the development box, but fails to move files when deployed to the enterprise server.

I dropped the fileAge parameter down to 150000ms, and then down to 30ms with the same results. Putting logging into DEBUG mode shows that every 5 minutes the file is found, but then is rejected with: "DEBUG org.mule.transport.file.FileMessageReceiver - The file has not aged enough yet" even with the fileAge reduced to 30ms. The file was put into the directory over 20 hours ago and has not been modified since and directories show a time/date on the file matching this. Permissions have been verified on the file and directory and the flow is locating the file, simply not accepting it is old enough to meet the criteria, and this only fails in the network environment.

Is there any ideas? Is it possible to at a global level change the units on the age parameter such that it is reading this as days instead of milliseconds for instance? Other applications in our environment are reporting similar issues with SFTP endpoints, and with that you can instead use checkFileSizeTime to escape the situation, but not with the File option.

Here is a simplified form of the flow, using a connector for the age parameter rather than putting it into the endpoint:

<file:connector name="fileConnector" doc:name="myFile"   fileAge="${MinSourceAge}" >
</file:connector>

<!-- Monitor source folder for files.  When found, move and archive them. -->
<flow name="printFlow">

     <file:inbound-endpoint path="${SourcePath}" 
                           pollingFrequency="${PollingFrequency}" 
                           responseTimeout="10000"
                           connector-ref="fileConnector" 
                           doc:name="GetPrintFile">
        <file:filename-regex-filter pattern="${SourcePattern}" caseSensitive="false"/>
    </file:inbound-endpoint>

    <logger message="#[message.inboundProperties.originalFilename] being sent to print dispatch." level="INFO" doc:name="Logger"/>

    <file:outbound-endpoint responseTimeout="10000" doc:name="Send To Archive" 
                            outputPattern="${ArchiveName}" 
                            path="${ArchivePath}" />
</flow>

The flow works just fine locally, only fails when deployed to the enterprise server. I created a test flow which does not use the age parameter then makes the same call to System.getCurrentMillis() the Mule class is supposed to use and I have it log this time and the lastModified timestamp from the file it states is not old enough and these timestamps should pass the test. And yes, I have removed the setting of the values through a property file and put the parameters directly into the flow. It finds the correct file, at the correct polling rate, but fails the age test.

Answer 1

OK, I forgot this question was posted, I should have answered it myself when I learned what is happening.

This is a bug in mule. It was submitted to them.

The bug is that when file age parameters are added to file endpoints, rather that keeping this information with the instance, Mulesoft (in error) over-rides the default file age parameter value, so that frequency now applies to all instances, not just the one it was declared for.

If a 2nd endpoint is declared with a different file age parameter, that one then again over-rides and becomes the default value, so whatever value is the last one scanned at start-up becomes the default value for every endpoint. If you declare one endpoint with a 10 second file age, and another with 10 days, it could be either value according to the order of code or order files are loaded, but all endpoints would be the same value applied.

The work-around for this is if you want more than one file-age parameter, you need to do it via connector, not directly on the endpoint.