Maximum amount of items included in (scheduled) transfer as transfer property

The implementation of MFT agents is unstable, particularly in situations involving the transfer of hundreds of files. It frequently occurs that a transfer will stall, and the agents involved become unresponsive, requiring manual intervention. Repeated new releases and PMRs have not improved the stability of the product.

One addition to the transfer that would, at least in our case, improve stability, is to limit the number of items for a transfer if the source is a filesystem. This could be done by adding a property to the transfer definition. As an example, a standard transfer definition, with the attribute @maxMatches added to the <source>/<file> element:

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

<request version="3.00" xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="FileTransfer.xsd">

<managedTransfer>

<originator>

<hostName>example.com.</hostName>

<userID>fteuser</userID>

</originator>

<sourceAgent QMgr="agent1qm" agent="AGENT1"/>

<destinationAgent QMgr="agent2qm" agent="AGENT2"/>

<transferSet>

<item checksumMethod="MD5" mode="binary">

<source disposition="delete" recursive="false">

<file maxMatches="32">c:\sourcefiles\*.jpg</file>

</source>

<destination exist="error" type="directory">

<file>/targetfiles/images</file>

</destination>

</item>

</transferSet>

</managedTransfer>

</request>

Such a feature would allow a transfer to be split up in multiple smaller transfers, reducing the incidence of stalling transfers as well as the impact of a stalled transfer, and the need for manual intervention.