0
votes

In the middile of the mule flow I'm using mule-requester module to pull some file and drop it to different location

<mulerequester:request 
resource="file://D:/CITI/PHACE2/IRM/processing/outbound/zip-in?connector=empty-conn" 
     doc:name="Mule Requester"/>
<file:outbound-endpoint path="${zip.file.out.path}" 
     outputPattern="#[message.inboundProperties.originalFilename]" 
     responseTimeout="10000" doc:name="File" connector-ref="File"/>

I have 3 files in above folder. A.zip, B.zip and C.zip for example. only A.zip is dropping to destination folder.

I also tried with adding file inbound connector name in mulerequester resource instead of file path. That also did not worked.

1
Try using "Request collection" operation available in mule requester Ex : <mulerequester:request-collection config-ref="Mule_Requester" resource="file://C:/Users/rnarkedamilli/Desktop/request-testing/input?connector=empty-conn" doc:name="Mule Requester"/>RamakrishnaN

1 Answers

0
votes

Mule Requester, with resources of type File, does not work correctly with the collection option. There is a footnote that they claim addresses this, but it is not obvious or clear that it is saying don't do it.

The issue occurs because of the mechanics and timing of the resource fetch. In the base libraries for these resources, there are two mechanisms, used according to how the resource is requested. In inbound endpoint, a polling mechanism is used, which returns all files that match the poll as a list which are them threaded as separate finds. In the method used by the requester, it is a single inquiry which returns only one file.

The collection option will get a list, and this works great for something like a JMS queue, but not for files. With a JMS queue, the resource is removed from the queue when you ask for it, so if you ask for 5 or all, you get 5 or all. With files though, the file is not removed from the directory until you finish processing in, so it you ask for 5, you get 5 streams to the same file because each returns the first on found, and it has not been removed yet, so the next request finds it again. If you ask for all (-1), it simply goes into an infinite loop sending you the same stream over and over.

This potentially could be fixed, but will take a re-write of the entire requester. The work-around is to request, process, repeat until no more files are found, or maybe custom code to get a list of files available, then request each by name in the order you want them would be a couple of options.