I have a service that does an ftp (pub.client.ftp) to an external partner that is no longer working. I am receiving a Connection Refused error (no FTP error code returned in this error). The external partner is not seeing any activity in their logs and my firewall group is not seeing us hitting the firewall. Though Unix OS FTP works fine to the external partner. This service was working fine two weeks ago, with no known changes since. I am at a loss to explain this and I am thinking of restarting IS, but this is a drastic step that I’m not sure is going to fix the problem. Any guidance or suggestions on what/where to look at would be appreciated.
look in the service usage and see if this service is stuck, you should see pub.client.ftp and in parenthesis a number e.g., 2,3,4 etc., right after the name of the service. If this is the case you need to restart your IS or reload the package whatever helps.
Are you sure there weren’t any OS level patches applied to the Unix box (security, firewall, etc.)? Can you see anything in your server log? It’s surprising that you get a Connection Refused error and no FTP return code.
Just as a test, perhaps you can build a separate flow service on that same server that also calls pub.client:ftp? And then build another service that calls pub.client.ftp:login, put, logout separately. It’s likely that the login service is failing. See what kind of errors you get back and maybe that will provide some clues.
Good luck!
Rajesh
Adnan,
Yes, I did look at the service usage. In fact, I was hoping to see a hung service since the problem would then be easy to fix by restarting IS.
Rajesh,
I had already done both of your suggestions and ended up with the same results. Though, not getting a return code back isn’t really that unusual, since I am not making contact with the target FTP server. Only if I can hit that server would I get a code.
I’ve also opened an incident with webMethods support regarding this. I’ll update with the solution when it is found. I have not tried to just restart IS yet, I’m basically leaving that as my last option since this is a production server with high traffic.
one option is to install another instance of wM on that box, with same options as the currrent install, execute these services in new instance and monitor the behaviour. If the same issue exists then definitely something wrong with the box, if not then probably package is corrupt. In this case you can try replacing the package in the old instance by copying it over from new instance Or archive it and install through admin console.