(DONE) Probleme mit RFT und WS-GRAM FileStageIn bei IG Testing vom 01.11.2006

Submitted by Andreas Hoheisel on Wed, 01/11/2006 - 13:44.
Hallo,


Das aktuelle instant-grid-testing.iso vom 01.11.2006 scheint ein Problem mit RFT und mit dem FileStageIn bei WS-GRAM zu haben. Wenn ich einen Job, der FileStageIn-Elemente enthält, mit globusrun-ws abschicke, dann erhalte ich meistens (aber nicht immer) nach einiger Zeit einen "421 Idle Timout"-Fehler.


Hier meine Kommandozeile:

globusrun-ws -submit -S -F https://bombay:8443/wsrf/services/ManagedJobFactoryService -f cat_instant-grid_filestagein.xml
Die job-Datei cat_instant-grid_filestagein.xml kann hier heruntergeladen werden.


Hier die Fehlermeldung:

globusrun-ws: Job failed: Staging error for RSL element fileStageIn.
Error authenticating user at source/dest hostServer refused performing the request. Custom message: 
Server refused GSSAPI authentication. (error code 1) [Nested exception message:  Custom message: Unexpected reply: 
421 Idle Timeout: closing control connection.] [Caused by: Server refused performing the request. Custom message: 
Server refused GSSAPI authentication. 
(error code 1) [Nested exception message:  Custom message: 
Unexpected reply: 421 Idle Timeout: closing control connection.]]
Error authenticating user at source/dest hostServer refused performing the request. Custom message: 
Server refused GSSAPI authentication. (error code 1) [Nested exception message:  Custom message: Unexpected reply: 
421 Idle Timeout: closing control connection.] [Caused by: Server refused performing the request. Custom message: 
Server refused GSSAPI authentication. 
(error code 1) [Nested exception message:  Custom message: Unexpected reply: 421 Idle Timeout: closing control connection.]]


Kann bitte jemand dieses Problem verifizieren? Danke, Andreas

Ich habe es gerade im

Ich habe es gerade im heutigen (2.11.) Nightly-Build probiert, da hat es bei 10 Versuchen keinen Fehler gegeben. Tritt das Problem bei Dir auch nicht mehr auf, wenn es einmal funktioniert hat? Oder tritt es erst nach längerer Laufzeit auf?

timeout bei RFT

Also prinzipiell dauert bei mir jeder RFT-Vorgang mindestens etwa 70 Sekunden, was darauf hindeutet, dass hier irgendetwas "hängt". Im Fraunhofer Resource Grid benötigt ein globus-url-copy unter einer Sekunde! Oft bekomme ich bei Instant-Grid einen timeout, manchmal funktioniert es aber. Kann das evtl. damit zusammenhängen, das meine Testrechner nur 500MB Hauptspeicher haben?

Nachgemessen

In vmware mit 512MB auf dem Server und 256MB auf dem Client benötigt Dein Beispiel (inkl. submit, clean-up, etc.) bei mir im Schnitt 10 Sekunden (laut "time"). Am Hauptspeicher per se liegt es also nicht. Das Problem resultiert vielleicht aus etwas, was Du vorher tust. Kannst Du es mal mit einem frisch gestarteten IG probieren?

auch Nachgemessen

Ich habe es nochmal mit globus-url-copy auf einem ultra-frischen Instant-Grid probiert, mit dem Ergebnis:
server:0 13:07:43 knoppix $ date; globus-url-copy file:///usr/local/gwes/LICENSE.txt gsiftp://bombay//tmp/test1 ; date
Fr Nov  3 13:07:56 CET 2006
Fr Nov  3 13:09:08 CET 2006
Macht 72 Sekunden.


Vielleicht liegt das auch daran, dass mein Instant-Grid keine Verbindung zum Internet hat? Da braucht nur irgendwo ein validierender Parser in einem der Globus-Dienste zu sitzen, der auf ein externes XML-Schema wartet. Oder Globus versucht anderweitig eine Verbindung ins WAN aufzumachen...

Reproduziert

In der Tat: Durch Entfernen der Default-Route konnte ich den Fehler auf Anhieb reproduzieren. Ich bin allerdings nicht sicher, ob wir dieses Problem auch beseitigen können, da es offenbar im Globus-Dienst selbst entsteht. Es könnte sich zumindest als aufwändig erweisen.

==> Globus Team

Ich denke, wir sollten das Globus-Team direkt diesbezüglich befragen bzw. auf das Problem hinweisen. Vielleicht können die uns da schnell weiterhelfen.

globus usage statistics

Der Parameter "usageStatisticsTargets" in $GLOBUS_LOCATION/etc/globus_wsrf_core/server-config.wsdd ist immer noch gesetzt! Daher versucht Globus bei jeder Aktion eine Nachricht an usage-stats.globus.org:4810 zu schicken. Siehe auch diesen alten Foreneintrag. Vielleicht erklärt das den Hänger.

Stats disabled

Hi,

das hatte ich auch gerade rausgefunden. Es lässt sich durch Konfigruation des GridFTP-Servers mit "disable_usage_stats 1" in $GLOBUS_HOME/etc/gridftp.conf abschalten und wird ab dem nächsten nightly-build enthalten sein.

Gruß, Andreas

GridFTP-Server ungleich globus-container?!

Wird die Einstellung bei GridFTP direkt für globus-container übernommen? Wenn nicht, bitte trotzdem die Änderung auch für globus-container vornehmen....

Ich denke wir sollten mal alle Dienste mit strace -e trace=network laufen lassen, um wirklich zu sehen, wohin noch alles kommuniziert wird.

Nein, es sind noch einige

Nein, es sind noch einige andere Konfigurationsdateien anzupassen (siehe http://www.globus.org/toolkit/docs/development/4.1.0/Usage_Stats.html). Ich komme heute jedoch nicht mehr dazu und werde mich am Dienstag damit beschäftigen, falls sich bis dahin niemand anderes berufen fühlt. :)
Viele Grüße und schönes Wochenende, Andreas

Jetzt sollten keine

Jetzt sollten keine Statistics mehr gesendet werden.

DONE

Nachdem ich bei gridftp und globus-container die usage statistics ausgeschaltet habe, brauche ich 8 Sekunden für einen job inklusive FileStageIn.