Yes, but we have some security policies and network concerns about using Globus Online. That's why we have developed an web application.
2015-06-23 17:44 GMT-03:00 Foster, Ian T. <fos...@anl.gov>: > Have you considered using the Globus transfer service? (Globus.org) > > On Jun 23, 2015, at 3:43 PM, Fabio Moreira <souza.fab...@gmail.com> wrote: > > 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 > > -- Fábio MS
