I believe the java rft client is hanging because it is not properly detecting completion. I believe this won't happen with globus-crft
-----Original Message----- From: Adam Bazinet <[email protected]> Sent: December 30, 2008 5:00 PM To: [email protected] Cc: GT User <[email protected]> Subject: Re: [gt-user] problem with rft directory transfer The server logs show nothing with a level of 'error'; I suppose I can turn on info, warn, all, etc. In the container log, the error is only tripped once. After it is tripped, the file transfer does continue ( I can watch a directory fill up ): gridt...@valine:>find . -name "*" | wc 108 108 1867 gridt...@valine:>find . -name "*" | wc 109 109 1903 gridt...@valine:>find . -name "*" | wc 113 113 2013 (etc.) But the fact that it is just hanging afterwards is killing things right now. I'll continue to look into it, but if you have ideas for things I can try, please let me know, since this is crippling our entire system at the moment. Also, I know that globus-url-copy is rather fast; it's clearly the overhead of RFT and the things you've described that are making it slow. It will be interesting to see how globus-crft compares. thanks, Adam On Tue, Dec 30, 2008 at 5:52 PM, <[email protected]> wrote: > I ment the globus container logs, but the gridftp server logs can tell the > same thing. > > How does globus-url-copy compare to scp? Alos you should try globus -crft > because part of the problem is the jvm start up time on the client. Another > reason is the needed security delegation, and probably the largest part is > the transactions required to enter everything in the database. > > -----Original Message----- > From: Adam Bazinet <[email protected]> > Sent: December 30, 2008 2:48 PM > To: John Bresnahan <[email protected]> > Cc: GT User <[email protected]> > Subject: Re: [gt-user] problem with rft directory transfer > > On Tue, Dec 30, 2008 at 2:27 PM, John Bresnahan <[email protected] > >wrote: > > > The retries is already set to 10, correct? But the docs say this is for > a > >> 'non-fatal' error. The problem is that when this error occurs, the > client > >> processes seem to be "hung" -- there is seemingly nothing happening. Is > >> there another way to specify re-tries with the rft command line client? > >> Something analogous to the <maxAttempts> field in RSL? > >> > > > > In 4.2 every error should be considered nonfatal, so retries will happen. > > 10 may not be a high enough value, can you look in the server logs to > see > > if this error is tripped many times? > > > > > > I assume you mean the gridftp log, which I had to turn on (hopefully the > error log will suffice) > > Now I'm waiting for the error to happen again. > > One other question, in the meantime. Why is RFT so slow? The same > recursive directory transfer between hosts takes all of 3 or 4 seconds, and > with RFT each one takes several minutes- a huge difference. It's always > been this way, and I've just accepted it- but never thought to ask why. > > thanks, > Adam > > > > > > > > > > As you can see, one comes from 4.2.1, one from 4.2.0. Would upgrading > >> valine to 4.2.1 help, if you think this is a GridFTP server issue? It > >> sounded like you weren't so sure using globus-crft would help, although > I > >> will see about using it anyway. > >> > > > > since this appears to be a server side issue there is no reason other > than > > dumb luck that globus-crft would help. However, globus-crft tends to be > a > > better tool in general so i recommend using it. > > > >
