Test des GWES in Release 0.5

Submitted by Dietmar Sommerfeld on Wed, 18/10/2006 - 09:50.

Hallo,

ich habe jetzt einen Workflow für POV-RAY geschrieben und ihn mit dem GWES im aktuellen Release 0.5 getestet. Dabei habe ich festgestellt, daß der FileTransfer Service nicht funktioniert. Zum Reproduzieren des Fehlers genügt es bereits, den Beispiel-Workflow gworkflowdl_rft.xml auszuführen.

Desweiteren wird der Workflow povray2-4tokens.xml (im Archiv) immer sofort wegen einer "Take Choice" mit "unresolved decisions" suspendiert. Wie lässt sich dies umgehen, ohne wie in povray2-4places.xml alle Eingabeparameter x-mal vorzuhalten?

Zuletzt ist mir aufgefallen, dass die Anzahl Uhren einer aktiven Transition zwischen 1-4 variiert. Hat dies einen bestimmten Grund?

Alle nötigen Dateien zum Testen des Workflow finden sich in folgendem Archiv. Nach dem Booten muss von root das Skript xml/testing/installer2.sh ausgeführt werden. Evtl. ist zuvor noch USBDISKDIR anzupassen.

Viele Grüße,
Dietmar

GWES in Release 0.5

Ab Donnerstag werde ich intesiv testen und debuggen, hier ein paar kurze Antworten:
  • gworkflowdl_rft.xml: Werde ich noch testen/debuggen, bei uns lokal gibts damit keine Probleme
  • povray2-4tokens.xml: Sinnvoller wäre hier, anstatt 4 tokens auf einer Stelle, 1 token mit anschließendem "AND-Split" auf vier einzelne Stellen zu modellieren (siehe Beispiel "gwes/examples/controlflow/gworkflowdl_duplicate.xml"). Dann ist der Prozess klar definiert, und es gibt keinen "Take Choice"-Konflikt im Sinne eines Petri-Netzes.
  • Viele Uhren: Dieser einigermaßen lustige Bug ist im aktuellem GWES behoben.

RFT-Fehler

Den FileTransfer-Fehler haben wir für das POV-RAY Beispiel analysiert. Es liegt daran, dass die Quelldatei nicht gefunden wird: statt
/home/knoppix/.gwes/<ACTIVITY_ID>/outputimage.<ACTIVITY_ID>.dat
wird versucht,
/.gwes/<ACTIVITY_ID>/outputimage.<ACTIVITY_ID>.dat
zu kopieren.
Ursache dürfte die unterschiedliche Interpretation von gsiftp-URLs sein. GWES interpretiert
gsiftp://server/tmp/datei.dat als server:/home/knoppix/tmp/datei.dat und erst
gsiftp://server//tmp/datei.dat wirklich als server:/tmp/datei.dat.
Der FileTransfer Service tut dies vermutlich nicht.

RFT-Fehler

Hallo,

es ist durchaus üblich, dass man mit der Angabe des host-names erst mal in einem user-Verzeichnis landet und ich kenne dieses Verhalten eigentlich auch von GridFTP (bzw. RFT). Ich habe den FileTransfer bisher allerdings nur lokal bei uns im Grid getestet und nicht auf Instant-Grid. Ab Donnerstag werde ich die Sachen mal debuggen, morgen und übermorgen muss ich erst mal nach Kassel.

Vielleicht hängt das auch mit der Definition des temporären workflow-Verzeichnisses in gwes.properties zusammen.

RFT-Fehler (relativer Pfad)

Ist schon vertrackt mit Globus. Also: das fileStageIn in WS-GRAM scheint relative Pfade in gsiftp-URLs zu vertragen, RFT hingegen nicht (bzw. nur wenn man globus-url-copy -rp aufruft). Ich würde vorschlagen, dass wir, bis dieser Bug behoben ist, erst mal nur absolute Pfade verwenden. Hierzu muss in gwes.properties z.B. gwes.gram.home.directory=/tmp/.gwes eingetragen werden.

Siehe auch Diskussion im Globus Forum