I am trying to get the GridFTP server working on my hosts. I am using the latest version 5.2.2 on Redhat 6.2, but I have seen the same problem with earlier versions of Globus. What I am seeing is:
- When starting GridFTP via xinetd.d, as thread count increases whether it is from more globus-url-copy commands or use of -cc, I wil eventually get the error: ts=2012-09-19T03:19:55.692900Z id=15907 event=globus-gridftp-server.transfer.error file=... msg="callback failed. an end-of-file was reached globus_xio: An end of file occurred " status=-1 On the client I will get the same errors: error: an end-of-file was reached globus_xio: An end of file occurred I also have a server setup using sshftp, and I have the same problems. Too many threads (more than 8 or 16) I will get connections that die with the error message above. I have not correlated to see if there is a one to one error between getting this message on the client and getting it on the server. Have also tried using the server based method (launched from /etc/init.d/globus-url-copy). While I haven't tuned any parameters on the server for either this method or xinet.d,the performance here seems worse. Its hard to characterize what is going on, but it seems to be that with the server method, that globus-url-copy commands seem to go to sleep while other transfers are going on. I am trying to flood a 10Gbe pipe where the latency between systems is 50ms. This is also an active connection so other things are going on as well. Which method, xinetd or server daemon, is most often used or preferred? Is there a tuning parameter as to how the client will back off or be aggressive at sending data based on the load it sees? If so is it tunable? Is there any reason why I should see different performance between the two methods? Thanks, Craig
