Moin Jürg,
Nein, nicht unbedingt bzw. kann man bei Vorliegen gewisser Randbedingungen schon auch auf Seiten des toolclients parallel agieren.
Das "Wesen" des toolclient ist ja, daß er Daten übergeben bekommt, diese zum Toolserver überträgt, dort die Verarbeitung stattfindet (der toolclient währenddessen wartet), dann das Ergebnis zurückkommt (der toolclient währenddessen wartet), und dann der Task erst vollständig beendet ist (und ggf. in einem Skript, innerhalb dessen der toolclient aufgerufen wurde, noch Nachbearbeitung der vom Toolserver gelieferten Ergebnisse geschieht). D.h. der entsprechende toolclient -- wenn direkt aufgerufen -- blockiert quasi sowohl Drucker-Queues als auch Scriptserver-Hotfolder.
Was angesichts der mit dem Toolserver möglichen Aktionen (bspw. Skripting von Mac-Programmen per AppleEvents/AppleSkript) auch gar nicht so dumm ist, weil diese ja wirklich immer nur sequentiell auf einem Toolserver ablaufen dürfen.
Will man hier LoadBalancing betreiben (und hat bspw. mehrere physisch existente Toolserver, auf denen mit AppleEvents agiert wird bzw. einen Toolserver, auf dem problemlos Tasks parallel laufen können -- bspw. weil sie nichts mit AppleEvents zu tun haben), dann ist die Lösung die, den toolclient als blockierendes Element auszuschließen.
Geht bspw. insofern als der ScriptServer-Handler bzw. das Notification Script einer Druckerqueue nicht direkt den toolclient aufruft sondern quasi forkt.
Ich habe also auf dem Helios-Server drei Skripte:
* eines das am Hotfolder oder der Druckerqueue hängt, von Helios Dateien entgegennimmt, und mit dem Pfad zur Datei das zweite aufruft.
* das zweite Skript (das sich dann selbständig darum kümmern muß, daß nur eine gewisse Anzahl Tasks parallel laufen) prüft die Randbedingungen (bspw. max. 4 Ausführungen parallel), wenn diese passen, übergibt es wiederum die Datei ans dritte Skript und beendet sich parallel (damit keine Blockade von ScriptServer oder Druckerqueue). Im anderen Fall (bspw. es laufen gerade 4 parallele Toolserver-Tasks) wird die Ausführung so lange verzögert, bis wieder ein Slot frei ist. Damit in diesem Fall solange Blockade von Skriptserver/Spoolerqueue wie nötig.
* das dritte Skript macht dann die eigentliche Arbeit, unter anderem den toolclient-Aufruf und die Nachbearbeitung der Dateien.
Das Ganze ist aber bei weitem nicht so trivial, wie es klingt (v.a. muß man die Ausführungszeiten der Skripte im Hinterkopf behalten, sonst fliegt einem sehr schnell einiges um die Ohren. Parallel muß man bedenken, daß man keine Situation herbeiführt, bei der mehrere Tools auf dem Toolserver per AppleEvents agieren, weil das schnell in die Hose geht.)
Und wenn man sich diese 3-stufige Skript-Architektur nicht gut überlegt (und bspw. die ersten beiden Skripte universell hält, sie also ohne Änderungen an beliebige Hotfolder/Druckerqueues dranschnallen kann und diese Skripte durch bspw. den Druckernamen wissen, welches eigentliche endgültige Skript sie aufrufen sollen), dann kommt man sehr schnell in den Skripting-Wald (gut für den Admin, denn der wird plötzlich unkündbar -- schlecht für den Betrieb, weil solche Sachen schon nach wenigen Wochen nicht mehr wartbar sind, weil nicht mal mehr der, der das Ganze eingerichtet hat, mehr durchblickt)
Hauptnachteil obigen Ansatzes: Die Ausführung des eigentlichen Skripts ist komplett von Helios abstrahiert, d.h. Rückmeldungen, die normalerweise dazu führen, daß irgendwas in der scriptsrv.log-Datei erscheint bzw. im Falle von Notification Scripts dafür sorgen können, daß der Druckjob in eine Fehlerqueue verschoben wird inkl. Benachrichtigung des Users (IMO nach wie vor eines der mächtigsten und gleichzeitig am Seltensten genutzten Helios-Features -- Job-Routing auf dem Server), sind nicht mehr möglich.
Aber es gibt Situationen, wo man nicht drumherum kommt, so zu agieren (muß grad in einem Projekt bei einem Kunden anstatt auf unser eigenes "k-remote" aus "politischen Gründen" auf den Toolserver setzen, der für die angedachte Aufgabenstellung in seiner Standard-Funktionsweise um ein Zigfaches langsamer ist -- ohne solche Verfahren wie oben müssten wir da wohl noch 5-6 8-Core MacPro aufstellen, um eine vergleichbare Performance zu erreichen)
Gruss,
Thomas
als Antwort auf: [#386718]
