Bugzilla – Full Text Bug Listing
|Summary:||RFT issues DCAU commands regardless of server support|
|Product:||RFT||Reporter:||Jan Ploski <Jan.Ploski@offis.de>|
|Component:||RFT||Assignee:||Ravi Madduri <firstname.lastname@example.org>|
|Severity:||normal||CC:||email@example.com, firstname.lastname@example.org, email@example.com|
When contacting the source server (and probably the destination server as well), RFT issues the "dcau N" or "dcau A" command regardless of whether the server supports it or not. This can result in an immediate error and aborted transfer: Error:Unable to set transfer optionsServer refused performing the request. Custom message: (error code 1) [Nested exception message: Custom message: Unexpected reply: 500 'dcau N': command not understood] [Caused by: Server refused performing the request. Custom message: (error code 1) [Nested exception message: Custom message: Unexpected reply: 500 'dcau N': command not understood]] globus-url-copy, on the other hand, is smart enough not to issue the "dcau N" if the option -nodcau is specified and the server does not report 'DCAU' in the output of the 'FEAT' command. The server which is causing problems with RFT is the dCache GSI FTP Door. I suspect that this is what makes staging from/to dCache with WS GRAM impossible.
Good point. Sorry, I forgot that when i answered on your e-mail in this matter. I once tried to get RFT running with dCache and kept stuck because of this. It seems to be the underlying GridFTPClient.setDataChannelAuthentication() in jglobus which is responsible for this. If i remember right then RFT also uses the MLST command to be able to set file permissions on the destination side like they are on the source side after transferring files. This may not be supported by other GridFTP implementations too. But this is something you can make RFT ignore by setting the flag ignoreFilePermErr in the rftOptions element of a transfer description. (Note that globus-url-copy does not adjust file permissions on the server-side after a transfer) RFT will be re-written and i added that topic to the discussion. I think support for other GridFTP implementations is planned. Plans are that Gram4 will use that new RFT then for staging purposes. Rob and Ann (on CC) may add more details about what and when.
JGlobus is not to blame - we also use JGlobus in our own GridFTP client and we managed to carefully avoid all the dCache show-stoppers. (MLSD is definitely not supported by dCache; I don't know about MLST.) We have gathered quite a list of observed dCache deficiencies in our project (most related to the handling of file attributes and ownership) which we will be forwarding to the German Grid support project for consideration. However, the main point is that even the current version of dCache could work for file staging with some slight adjustments in RFT.
There's limited development effort in RFT at the moment for various reasons. Would you be willing to provide a patch?
I'd provide a patch if I could quickly set up a development environment (in Eclipse) for modifying and debugging the RFT code. How easy is that?
export CVSROOT=:pserver:firstname.lastname@example.org:/home/globdev/CVS/globus-packages cvs co -r globus_4_0_branch packaging cd packaging ./make-packages.pl --bundles=gt4-rft --deps --skippackage --skipbundle You then have a checkout of RFT and its dependencies under packaging/source-trees. You can then build your modified RFT by running: ./make-packages.pl --bundles=gt4-rft --install=/path/to/install
In RFTOptionsType there is a option you can set to turn off DCAU. IF you are using rft command line client you can see the documentation here to set it to appropriate value: http://www.globus.org/toolkit/docs/4.0/data/rft/rn01re01.html
The latter command fails with (the last few lines): Checking out cvs tree gt4. Updating CVS checkout of :pserver:email@example.com:/home/globdev/CVS/globus-packages Queueing ws-delegation on update command. Queueing ws-mds on update command. Queueing ws-transfer on update command. Queueing wsrf on update command. Logging to /home/jploski/workspace-3.2/packaging/./log-output/cvs-logs/gt4.log ERROR: Trouble with cvs up on tree gt4. at ./make-packages.pl line 900, <TAG> line 14. In the log file I see quite a few reported CVS conflicts, like: cvs update: move away `ws-mds/servicegroup/schema/inmemorysg/InMemoryServiceGroupEntry_bindings.wsdl'; it is in the way
(In reply to comment #6) > In RFTOptionsType there is a option you can set to turn off DCAU. IF you are > using rft command line client you can see the documentation here to set it to > appropriate value: > http://www.globus.org/toolkit/docs/4.0/data/rft/rn01re01.html Unfortunately, this is not sufficient. See the original problem report above which describes the unwanted consequences of turning off DCAU in RFT.
ah.. I see it now. Let me see if I can fix it real quick.
Sorry, the latter command should read: ./make-packages.pl --bundles=gt4-rft -n --install=/path/to/install the -n turns off cvs updates (and the conflict
(In reply to comment #10) > Sorry, the latter command should read: > ./make-packages.pl --bundles=gt4-rft -n --install=/path/to/install > > the -n turns off cvs updates (and the conflict Still no luck: Trying to make bundle gt4-rft Installing gt4-rft to /tmp/gt4-rft using flavor gcc32dbg, flags . gpt-build ====> CHECKING BUILD DEPENDENCIES FOR globus_database_common ERROR: The following packages are missing Package globus_database_common-ANY-src is missing compile-globus_java_ws_core_common-ANY-pgm Died at /tmp/gt4-rft/sbin/gpt-build line 420. ERROR: Building of gt4-rft failed.
Sorry for not testing it first Jan. The installation command also needs --deps, or it won't install the required software. My usual method is to just use fait_accompli/installer.sh to get a full toolkit installer, I was just trying to save time by only having you check-out/build the RFT component.