Original issue 148 created by soi-toolkit on 2011-05-22T14:15:09.000Z:
This problem affects SFTP-resend service file-inbound endpoints and file-inbound endpoints in general.
Problem:
If the file-inbound polling interval is shorter than the time it takes to send/stream the file to an outbound endpoint (i.e. the file is still in the inbound-directory), then the file will be read again, resulting in duplicates for SFTP-outbound (if duplicateHandling="addSeqNo") or overwrites (for example in the case of a file-ountbound endpoint).
The re-reading will continue as long as the polling time < transmission time.
Original issue 148 created by soi-toolkit on 2011-05-22T14:15:09.000Z:
This problem affects SFTP-resend service file-inbound endpoints and file-inbound endpoints in general.
Problem:
If the file-inbound polling interval is shorter than the time it takes to send/stream the file to an outbound endpoint (i.e. the file is still in the inbound-directory), then the file will be read again, resulting in duplicates for SFTP-outbound (if duplicateHandling="addSeqNo") or overwrites (for example in the case of a file-ountbound endpoint). The re-reading will continue as long as the polling time < transmission time.
This seems to be a known problem with the file-transport, see: http://www.mulesoft.org/jira/browse/MULE-5374 http://www.mulesoft.org/jira/browse/MULE-5131
The bullet-proof solution seems to be to use the "workDirectory" attribute on the file-connector.