AW: Wunschzettel für Avanti

[Thomas Berger]

Lieber Herr Schmid,

> Der (animierte) Statusbalken ist hier nicht nur nette Unterhaltung. Man
> stelle sich eine Anwendung vor, die es erlaubt eine Avanti-Ergebnismenge zu
> bilden und diese per Download herunterzuladen. Da hat der User ja erstmal
> keine Ahnung, ob er nun 5 Treffer erhält oder 5000. Und das kann bei einem
> Download-Job mit einer entsprechenden Parameterdatei schon einen gewaltigen
> Unterschied machen. Der User hingegen sieht nur (d.h. er sieht nichts), daß
> sich nichts tut und denkt sich vielleicht, der Client oder Avanti sei
> abgestürzt.

Ihr Client darf ja durchaus Avanti dazu bringen, zunaechst einmal
mitzuteilen, wieviel kommt. Was Sie an "Protokoll" brauchen,
koennen Sie mit zwischengeschalteten Statusmitteilungen selber
kreieren:

write "STATUSINFO: Es kommen nun " lastnum " Datensaetze" newline

[Oder Sie machen zwei Jobs draus, dann kann der Benutzer
am Client auch noch ein Woertchen mitreden]

Die Gesamtzahl der zu uebertragenden Bytes zu uebermitteln,
halte ich fuer zu aufwendig. Auch die "chunked" HTTP 1.1-
Uebertragungen kennen nur die Groesse der unmittelbar folgenden
Portion, nicht die der Gesamtuebertragung: Normalerweise
ist es besser, sofort mit der Uebertragung zu beginnen,
als alles zu parken und erst mit sekunden- oder minutenlanger
Verzoegerung mit der Uebertragung anzufangen.


> Wenn Avanti den Job tatsächlich ignoriert, dann wird er auch keine
> Fehlermeldung schicken, nehm ich mal an.

Warum nicht? Immerhin wird hier eine Verbindung aufrechterhalten
oder getrennt, zumindest im Fall des "aktiven" Ignorierens.
Es stimmt natuerlich, dass avanti nichts tun wird, wenn ihn
nicht einmal ein einziges Byte des Jobs erreicht: Dann kann
er nicht unterscheiden, ob da einfach eine Verbindung nicht
abgebrochen wird oder ob der Client Daten gesendet hat.
Im Hinblick auf das Setzen von Timeouts und lange Ausfuehrungs-
zeiten von Jobs waere es vermutlich auch schick, wenn Avanti
den Erhalt eines Jobs quittieren wuerde (so wie Sie es vorgeschlagen
haben): Ein Client wuesste dann, dass alles auf dem Weg ist
und koennte seine Timeoutsetzungen entsprechend anpassen.
Das laesst sich uebrigens nicht mit write-Anweisungen
im Job bewerkstelligen: Typischerweise erfolgt ja erst
eine Uebertragung, wenn ein volles IP-Paket (im Weitverkehr
ca. 8kB) zusammengekommen ist, und das ist u.U. erst 
Minuten nach Start der Verarbeitung der Fall.


> Andere Frage: Was tut Avanti eigentlich, wenn die Verbindung vom Client
> gekappt wird, während er gerade das Ergebnis zusammenstellt, oder bereits
> einen Teil verschickt hat?

Das weiss glaube ich niemand so genau, nicht einmal Avanti :-)
Jedenfalls ist eine gute Strategie einerseits und Sauberkeit
bei der Ausfuehrung andererseits einer der kritischen Punkte
bei der Programmierung solcher Dinge.
Optimal saehe es vielleicht so aus: Sobald beim Schreiben
bemerkt wird, dass die Verbindung nicht mehr existiert
(d.h. der Schreibkanal meldet einen Socket-Fehler), sollte
die gesamte Verbindung abgebrochen werden (und die zugehoerigen
Ressourcen freigegeben) und vor allem auch das noch weiter
arbeitende Procav abgeschossen werden.
Momentan zu beobachten ist, dass Jobs bis zum avanti-Timeout
weiterlaufen, auch wenn ein Client ein kuerzeres Timeout
hat. Das fuehrt dann dazu, dass nachfolgende Jobs sich den
Prozessor mit dem noch laufenden alten Job teilen muessen
und noch eher Kandidaten fuer ein Timeout werden (das avanti-
Timeout ist in CPU-Sekunden bemessen, das der Clients in
Realzeit). So entsteht dann schnell eine Kettenreaktion
(schon beobachtet).
Man koennte darueber nachdenken, ob avanti und client nicht
moeglicherweise auch *optional* keep-alive-Meldungen austauschen 
sollten, dann besteht die Chance, einen Verbindungsabbruch des 
Clients recht frueh zu erkennen und die CPU-Ressourcen zu schonen 
(Avanti-Jobs rechnen ja erst einmal alles aus, danach erst kommt
typischerweise ein "download set")

viele Gruesse
Thomas Berger