傳輸完成后，為什么沒有SFTP入站（部署在Cloudhub上）刪除文件

Question

這個問題與此與此息息相關。 使用SFTP連接器時，流默認情況下處於打開狀態，並且無法關閉（版本3.5.2）。 如果我有如下流程

1）輪詢頻率較高的入站SFTP連接器（例如，以小時為單位）

2）出站文件以將流存儲到本地存儲中的文件中

我希望在這里，SFTP入站在傳輸完成后會刪除源文件。 （但這不會發生）

閱讀文檔，我發現以下內容

自動刪除（僅適用於入站SFTP端點）。 讀取文件后，單擊此框將其刪除。 注意：如果在將Mule寫入出站端點時發生錯誤，則不會刪除該文件。 僅當入站和出站端點都使用SFTP傳輸時，自動刪除才有效。

有沒有解決方法？基本上，從SFTP服務器下載源文件后，如何刪除源文件？

上面大部分是與文檔有關的問題，即使出站不是SFTP連接器，SFTP自動刪除功能仍然可以正常工作。 我已經在這里記錄了一個JIRA

更新：

我已經確定了問題的根本原因，當部署在cloudhub上時，SFTP連接器的輸出返回類java.io.ByteArrayInputStream的實例，但是當通過Anypoint Studio部署應用程序時，輸出是org.mule.transport.sftp.SftpInputStream類的實例。 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 INFO LoggerMessageProcessor：193-InputSFTPEndpoint org.mule.transport.sftp.SftpInputStream

我的流程如下所示

更新2：

但是，如果文件很大，我認為大約有10MB，則返回類型為com.google.common.io.MultiInputStream ，文件確實會被刪除。

有什么想法為什么Cloudhub會這樣？

Answer 1

我是Mulesoft的新手，並且遇到了相同的問題。 我發現，Mulesoft鎖定了正在讀取的文件。 對於我的特定情況，我正在讀取文件，然后上傳到Fusion（雲）。 Mulesoft不會自動刪除文件。 當它再次輪詢文件夾路徑時，它將在該位置看到相同的文件並嘗試再次讀取它。 我們必須執行的強制釋放文件的操作是在字符串中添加了字節數組。 似乎已迫使Mulesoft完整讀取文件並轉換有效載荷，從而切斷了文件的鎖定。