WM 4.0.1: Problems with pub.client.ftp

In our project, we are using the FTP client that ships with webMethods 4.0.1 sp 3, on a Windows 2000 sp 3 platform.

Occasionally, the FTP hangs during transfer, we suspect that the FTP library is the source of the problem; it seems to have a bug. We do not know which service of the pub.client.ftp package hangs. We do not know if this issue also applies to WM 4.6 or 6.0.

The “FTP hang” will in turn cause the flow service to hang. How do we know? It turns out that our corresponding flow services are scheduled services. The symptom then is that in the B2B Server’s “Scheduler” tasks, the corresponding service’s time will remain at 9.2 seconds. We found that “9.2 seconds” usually means that the service is active. But in our case, it then means “the service keeps hanging”. The only way we have to fix the above is to restart the B2B server. That is not really satisfying in a production environment.

We attempted to fix the issue in multiple ways:

  • Timed out sequences do not work. The timeout event only occurs after the ftp method returns, but it never returns. If timed out sequences were to interrupt the flow that is actually running, then that could help.
  • Calling pub.client.ftp.logout() does not solve the issue, because logout() only closes the FTP control connection, not the FTP data connection. But the call hangs on the data connection.
  • We also tried to use a Java solution involving a multithreaded “watchdog” that would interrupt() the blocked thread. To our dismay, the FTP transfer keeps on hanging.

We would know how to work around the issue: A watchdog mechanism would close the FTP control and data connections, after a given timeout. The blocked FTP transfer would simply receive an IO exception, and would exit.

We would like to help webMethods in working around that problem, but we are barred from doing so by the webMethods license agreement.

Hi,

to narrow your problem, you could try to use the Windows’ ftp Service, which is shipped and automaticaly started with Server editions.

In fact, this is what we do to use ftp, I never tried with a webMethods manually added ftp port…

Good luck,
Patrick.

I do not understand: You can use the FTP service on Windows (coming with IIS) as an FTP client?

Yes, we call “pub.client.ftp” without having installed an webMethods ftp port. So it will probably lookup it’s configuration for an installed port, and if none is found, try port 21 to see whether an external ftp service is installed on the pc. In this case the Windows’one.

I think this service is both a server and a client… at least a client, because you can also just ftp from the command prompt, right?

Hope I’m clear now.

Yes, we call “pub.client.ftp” without having installed an webMethods ftp port.

Then you are using the built-in CLIENT functionality of webMethods. That is the part that hangs on some occasions.

So it will probably lookup it’s configuration for an installed port, and if none is found, try port 21 to see whether an external ftp service is installed on the pc. In this case the Windows’one.

No. The pub.client.ftp acts like an FTP CLIENT, using TCP/IP sockets and the FTP protocol. Underneath, there are a couple of Java classes, see my initial post.

I think this service is both a server and a client… at least a client, because you can also just ftp from the command prompt, right?

No. There is an FTP.exe program, that one acts as a CLIENT. There is an FTP service under the Windows control panel, that acts as a SERVER. There is a pub.client.ftp WM service, and that one is a CLIENT too.

Hi All,
We have same problem when using pub.client.ftp. The Ftp service is also
having problem with multiple schedule services connecting to same Ftp
server for different purpose (webMethods shares the connections!).
The only solution i have is to write a WathDog that delete the service
and re-create it again using same data. Also a watchDog to shutdown and
restart the webMethods after 3 days, so that the hang data transfer and
invalid service usage count get Synched.

Hi All,
We have a similar problem with the ftp service.We have tried diff options like timeout, Service.doThreadInvoke etc but none of them gave satisfactory performance.Then we have created a shell script to do ftp and calling that script to execute ftp commands using the java runtime class. We had problems even with this approach as the os process which is executing the ftp command sometimes hangs.So the shell script has a timeout limit, beyond which it kills the os process using PID