webMethods - Pub.client.sftp:put not returning expected return code / message

pub.client.sftp:put not returning expected return code / message

webMethods 10.11 version and SFTP version 2

Hi,

We are using the inbuilt service pub.client.sftp:put service to transfer files to a SFTP target server. On the target server we could see that the files are placed, however the pub.client.sftp:put service returns a failure message. This happens only when we try to send large count of files at a time.
Does anyone know what could be the possible reason why failure is returned even though files are placed successfully.

Appreciate any inputs on this topic

An important part of being able to guess at what might be wrong is the specific error code and message that was seen.

1 Like

Below is the error message
Reason for failure - Delivery service for failed with a status of fail and status message of failed to copy the files to Remote - Error while executing command ‘put’: </path/filename> (No such file or directory)
The error message is a bit strange because the file has been placed at the target, but still its throws as no such file while executing put

Hi @csheetal ,

Perhaps you can ask the Target SFTP Team to verify if similar Failure message is appearing at their Logs too.

Additionally, you can enhance the SFTP(0147 SFTP Client) and Network (0064 Network Services) related Logging Level at your end to Trace or Debug to view if any additional error information gets captured in the Server Logs to aid your investigation.

Note : Enhancing the Logging Level to Trace or Debug will make your Server.log file size to grow exponentially. So ensure to quickly revert to the normal logging Level as soon as possible else your Drive/Disk space where Server.log is written will run out of space and lead to problems.

For Newer Version
Administration → Logging configuration → View server logger details
Under Integration Server Option


image

For Older Version
Settings → Logging → View Server Logger Details
Undrer Integration Server option
image
image

Thank you for the suggestion.
We enhanced the logging levels, but no additional logs related to this error was captured. When we further analyzed the logs, we could see that there was a success response after the file was placed in the target server from ‘put’ service and as per the logic the file was deleted from the local directory. But after few seconds the above failure message was recorded mentioning the ‘put’ service had failed.
One point to note is that, this issue occurs only when large number of files are transferred. In this case around 150+ files was transferred in a single run of the service.

In that case the flow service in which pub.client.sftp:put is being used, how is it being invoked. Is it a Scheduled service or a File Poller?

If you can share details about what is being passed to pub.client.sftp:put, application extended settings related to timeouts, etc. then perhaps someone may see something that could be investigated. Similarly, what are the settings on the SFTP server related to session timeouts and such, if those are available.

With the symptom being that this occurs with a “large” file count, it feels like there is a timeout of some sort. Might the size of a single file also be a factor? But these guesses seem to be a stretch as the connection is active.

In the spirit of “trust what the error message is telling you” – explore the possibilities of what could cause a “No such file or directory” error? Does the error occur always at the end of the list of files to be transferred? Or sometimes in the middle? Are filenames a factor?

IMO, running as a scheduled service or via file polling (or any other way) is most likely not a factor.

1 Like

As Rob suggested, please show details about how you create your session and how you make the calls. Show all the parameters you can share.

As it is, all we can do is just speculate, and trust me it will cause more harm then good for you. The most likely scenario is usually If you have a sleep somewhere between each loop, or if you have a timeout set to your put calls and if you are trying to push a big file, it can time out, session or put call. Tbh, it might even be your own validator service that is generating that response, there is no way to verify it, unless you provide actual data.