为什么 SFTP 入站(部署在 Cloudhub 上)在传输完成后不删除文件

Why does'nt SFTP inbound (deployed on Cloudhub) delete files after transfer is completed

这个问题与this and this关系密切。使用 SFTP 连接器时,流式传输在默认情况下处于打开状态且无法关闭(版本 3.5.2)。如果我有如下流程

1) 具有较大轮询频率(例如以小时为单位)的入站 SFTP 连接器

2) 文件出站以将流存储到本地存储中的文件中

我希望 SFTP 入站在传输完成后删除源文件。 (但这并没有发生)

阅读 documentation 我发现以下

Auto Delete (Applies to inbound SFTP endpoint only) . Click this box to delete the file after it has been read. Note: If an error occurs when Mule is writing to the outbound endpoint, the file is not deleted. Auto Delete only works if both the inbound and outbound endpoints use the SFTP transport.

有解决办法吗?基本上,从 SFTP 服务器下载源文件后如何删除它?

以上主要是文档的问题,即使出站不是 SFTP 连接器,SFTP 自动删除也能正常工作。我已经记录了关于它的 JIRA here

更新:

我已经确定了问题的根本原因,部署在 cloudhub returns class java.io.ByteArrayInputStream 实例时 SFTP 连接器的输出,但是当部署应用程序时通过 Anypoint studio,输出是 class org.mule.transport.sftp.SftpInputStream 的实例。

要复制请确保文件大小小于 2 MB

这会导致部署到Cloudhub上时文件不会被删除。

来自 cloudhub 的日志

本地部署日志

2015-04-28 15:37:50 DEBUG SftpConnectionFactory:118 - Successfully connected to: sftp://decision_1:####@XXXXXXX:22/To_DI_Local
2015-04-28 15:37:50 DEBUG SftpClient:121 - Attempting to cwd to: /To_DI_Local
2015-04-28 15:37:50 DEBUG SftpConnector:121 - Successfully changed working directory to: /To_DI_Local
2015-04-28 15:37:50 DEBUG SftpMessageReceiver:121 - Routing file: ZCCR_EXTRACT_FINAL.CSV
**2015-04-28 15:37:50 INFO  LoggerMessageProcessor:193 - InputSFTPEndpoint org.mule.transport.sftp.SftpInputStream**
2015-04-28 15:37:50 DEBUG SftpMessageReceiver:121 - Routed file: ZCCR_EXTRACT_FINAL.CSV
2015-04-28 15:37:50 DEBUG SftpMessageReceiver:121 - Polling. Routed all 1 files found at sftp://decision_1:####@XXXXXX:22/To_DI_Local

2015-04-28 15:37:50 信息 LoggerMessageProcessor:193 - InputSFTPEndpoint org.mule.transport.sftp.SftpInputStream

我的流程如下所示

更新二:

但是,如果文件很大,我认为大约 10MB,那么 return 类型是 com.google.common.io.MultiInputStream,文件确实会被删除。

知道为什么 Cloudhub 会这样吗?

我是 Mulesoft 的新手,遇到了同样的问题。我发现 Mulesoft 锁定了它正在读取的文件。对于我的特定场景,我正在读取一个文件,然后上传到 Fusion(云)。 Mulesoft 不会自动删除该文件。当它再次轮询文件夹路径时,它会在那里看到相同的文件并尝试再次读取它。为了强制释放文件,我们必须做的是将一个字节数组添加到字符串中。它似乎迫使 Mulesoft 读取整个文件并转换切断文件锁定的有效负载。