Hi, My team and I have developed an web application based on jGlobus and observed the same issue described by Xishi. However, instead of *extendedTransfer()*, we use *extendedMultipleTransfer()*, since we are transferring multiple files. What we observed is that the transfer hangs at 99% (observed by PerfMarkers), meaning that when the hanging occurs it is always when transferring the last part of the last file (or after its finish). It is also noteworthy that *org.globus.ftp.MultipleTransferCompleteListener#transferComplete() *is not informed that the file transfer has ended, even though the file has the same size in origin and destination.
I have tried looking jGLobus github project to check if any modifications implemented on version 1.8.0 to extendedTransfer() was missed in extendedMultipleTransfer, but github repository only tracks from jGlobus V2 ahead. The versions for each maven dependency is listed below. - JGlobus-Core : 2.0.4 - JGlobus-GridFTP: 2.0.0 - JGlobus-Tomcat: 2.0.4 - myproxy: 2.0.6 Globus Toolkit version (in both endpoints): 5.2.5 ___________________________________________________________________________________________ A similar issue was identified in jglobus and fixed in the most recent release 1.8.0. Please see if that version solves your problem. Xishi PAN wrote: >* Hi, *>* We are developing a transfer service with jGlobus1.7.0 and Globus *>* Toolkit 4.2.1. It's a multithreaded service. Each thread has an instance of *>* org.globus.ftp.GridFTPClient for 3rd-party transfers. *>* In some circumstances (for example, very heavy system load), we found *>* that a 3rd-party transfer cannot end occasionally even if the file has been *>* completely transferred. The work thread just hung there for hours. According *>* to the debug info,the sending end has already sent "226 Transfer Complete." *>* and I think its monitor thread has already exited according to the debug *>* message "thread dying naturally". *>* I've read some source codes about the *>* "org.globus.ftp.GridFTPClient.extendedTransfer()" call.I'm afraid the other *>* monitor thread is still blocking so function call "extendedTransfer" cannot *>* return normally. *>* Is it a known issue or Is there any workaround to this problem? *>* Currently we have created a guard thread to check if a transfer has been in *>* idle state for too long. *>* Any input will be appreciated. *>* Thanks!* -- Fábio MS
